Subject: [ipfix-req] Re: [ipfix] Terminology suggestion

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Feb 2002 16:29:49 +0100 (CET)

Hi Juergen,

Here are my input on this terminology, as promised during the conf. call.

Note that whether the definitions go into the requirements draft or in the architecture doesn't make any difference to me. This only thing of importance is that, if the requirement draft dissapears with the time, we don't want to loose the defintions. One solution is that the architecture document will have to repeat the definitions.

> 
> see draft-ietf-ipfix-reqs-00.txt, section 1.1

I just copied the definition from draft-ietf-ipfix-reqs-00.txt for completeness.
      A flow is a set of packets passing an observation point in the
      network during a certain time interval. All packets belonging to a
      particular flow have a set of common properties derived from the
      data contained in the packet and from the packet treatment at the
      observation point.

I would go a little bit further in the definition, by describing what a property coul be:
   A flow is defined as a set of packets passing an observation point in the
   network during a certain time interval. All packets belonging to a
   particular flow have a set of common properties.  Each property is
   defined as the result of applying a function to the values of:

     a. one or more of packet header fields (eg. destination IP address)
     b. one or more properties of the packet itself (eg. packet length)
     c. one or more of fields derived from packet treatment (eg. AS
        number)

   A packet is defined to belong to a flow if it matches all the defined
   properties of the flow. 

> 
> 2.2.   Observation Point
> The observation point is a location in the network where IP packets
> can be observed.  Examples are a line to which a probe is attached,
> a shared medium, such as an Ethernet-based LAN,  a port of a router,
> or an entire router with several ports.

I agree with the definition above, but I would be more specific:
The observation point is a location in the network where IP packets
can be observed.  Examples are a line to which a probe is attached,
a shared medium, such as an Ethernet-based LAN, a port of a router,
or an entire router with several ports. The observation is characterized 
by one or a set of interfaces (physical or logical) of the exporter.

Note: the exporter is defined below.
> 
> 2.3.   Trafic Flow Meter or Meter
> A  meter observes packets at one or more observation points.
> It analyzes the content of the packets and maps them to flows.
> For each observed flow the meter computes statistics and maintains
> a flow record where it stores relevant flow infromation.

I think that the concept of exporter makes more sense.
And I believe that you are mixing 2 definitions: 
- the exporter (ex: a router or a probe)
- the metering process which analyzes the traffic
So I would just remove this definition and leave the exporter/metering process 
as 2 definitions.

     * Exporter: The entity on which flows are measured and are
       exported. The exporter can be a router, a middlebox [2], or a
       traffic measurement probe.

> 
> 2.4.   Metering Process
> The metering process includes all actions performed by a meter
> with respect to observing packets, timestamping them, analyzing them,
> mapping them to flows, computing flow statistics, detecting flow
> expiration, and maintaining flow records.

Measurement process that is carried out at the observation domain.
The metering process includes all actions performed by a meter
with respect to observing packets, timestamping them, analyzing them,
mapping them to flows, computing flow statistics, detecting flow
expiration, and maintaining flow records.

Note: we had to introduce the concept of observation domain.

     * Observation Domain: The set of observation points which is the
       largest aggregatable set of flow information at the exporter is
       termed as an observation domain. The observation domain presents
       itself a unique ID to the collector for identifying the export
       packets generated by it.

       Example: The observation domian could be a router linecard,
       composed of several interfaces with each interface being an
       observation point.

Why the concept of observation domain?
Typically for a linecard on a router, which is an independant entity.
So an exporter can be composed of several observation domains (read linecards).
There is one metering process per observation domain (read linecard). 
You can do flow aggregations for these linecard flows but not between flows from different linecards.

Note: I agree that we are missing a high level picture of this in
draft-gsadasiv-ipfix-proposal-00.txt

> 
> 2.5.   Flow Record
> A flow record keeps information a flow including characteristic
> properties of the flow, for example the source IP address,
> and measured properties of the flow, for example the total number
> of bytes of all packets of the flow.

All packets belonging to a particular flow have a set of common properties.
But the flow record doesn't necessarily have the notion of its own properties.
I would remove the properties part. 
Here is the definition I would propose.

     * Flow Record: A flow record provides information about a specific
       flow that was measured at an observation point using a certain
       set of methods within an exporter.
> 
> 2.6.   Flow Information Exporter or Exporter
> The exporter sends flow records created and maintained by one or
> more meters to one or more data collectors.

See my previous remark about exporter versus meter

> 
> 2.7.  Flow Information Data Collector or Data Collector
> The data collector receives flow records from one or more exporters.
> The data collector might process or store received flow record,
> but these actions are out of the scope of this document.

OK. We called it just collector. But this is just a detail!

Regards, Benoit.

> 
> 2.8.   Flow Information Export
> Flow information export denotes the process of transferring flow
> records from an exporter to a data collector.
> 
> 
> --
> Help        mailto:[email-masked] and say "help" in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: [email-masked]
Date: Tue, 12 Feb 2002 01:03:21 +0100 (CET)

Hi Benoit,

Benoit Claise <[email-masked]> wrote:

> Note that whether the definitions go into the requirements draft or in
> the architecture doesn't make any difference to me. This only thing of
> importance is that, if the requirement draft dissapears with the time,
> we don't want to loose the defintions. One solution is that the
> architecture document will have to repeat the definitions.
> 
> > 

Fine. But we should mention somewhere that also partial matches might be
sufficient.

> by one or a set of interfaces (physical or logical) of the exporter.

I think the last sentence is too restrictive. Why excluding packet
samplers sending samples from a remote observation point to a meter?

> And I believe that you are mixing 2 definitions:

No, it's just the opposite: I want to separate meter and exporter.
 
>        traffic measurement probe.

Here you are mixing metering and exporting.

I see two function blocks in our architecture: The meter executing the
metering process and the exporter participating as sender in the flow
information export process.

> flows from different linecards.

Well you are approaching my hierarchy: 
exporter - meter - observation point

The meter processes (and aggregates) packets from one or more
observation points and generates flow records. The sum of its
observation points outlines your observation domain.
The exporter exports flow records produced by one or more meters.

First you say is "delete the term of meter" and then
"add the term of observation domain", because now we need it.

If you just keep the meter, you do not need the observation
domain and you have an concept which is easier to understand
and which also matches the function blocks of the architecture.

> See my previous remark about exporter versus meter

dito

> OK. We called it just collector. But this is just a detail!

Fine. What about the heading "Flow Information Collector or Collector"
and then renaming all data collectors into collectors?

Best wishes,

    Juergen

---

From: [email-masked]
Date: Tue, 12 Feb 2002 01:13:24 +0100 (CET)

Hi Benoit,

 

dito

Best wishes,

    Juergen

---

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 11 Feb 2002 18:13:17 -0800

Hi Jurgene,
  Some comments.

> Fine. But we should mention somewhere that also partial matches might be

The parial matches are covered when we say  "as the result of applying a function
to the values of:".

> samplers sending samples from a remote observation point to a meter?

I do not understand this. Can you elaborate?

> The exporter exports flow records produced by one or more meters.

I guess there is some confusion. The observation domain could
do some level of metering.
But metering itself is independent of an observation domain.
If I draw a picture of the inetntion of observation domain,
it would look like:

+---------------------------------------------------------------------+
|                    Observation Domain                               |
|          +------+                          +------+                 |
|          |Meter1|          ....            |MeterM| (Perform packet |
|          +------+                          +------+  metering)      |
|              ^                                  ^                   |
|              |                                  |                   |
|      +-------+--------+                 +-------+--------+          |
|      |                |                 |                |          |
|      v                v                 v                v          |
| +------------+   +------------+     +------------+   +-------------+|
| |Obsv Point11 |..|Obsv Point1k|     |Obsv PointM1|.. |Obsv PointMn ||
| +------------+   +------------+     +------------+   +-------------+|
+---------------------------------------------------------------------+
          ^                     ^
          |                     |
          v                     v
          +----------+          +----------+
     |Meter (O1)|   ....   |Meter (OP)| (Perform flow metering etc).
     +----------+          +----------+
              |                |
              +-------+--------+
                      |
                      v
               +---------------+
               |  exporter     |
               +---------------+

Another point to note is that in draft-gsadasiv-ipfix-proposal-00.txt,
we have made meter to observation point 1 to 1. Though theoritically
what is drawn above looks fine, I have a little difficulty in
understanding when this would be the case.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Feb 2002 13:28:19 +0100

Hi Juergen,

> Fine. But we should mention somewhere that also partial matches might be

This was implicit in our definition, i.e. the function could be anything.
If you still have problem, we can try to find another way to express it.

> samplers sending samples from a remote observation point to a meter?

1. If you have in mind a port copy, then you copy the packets from one
port to another port. So the observation point is an interface the packets are
copied to.

2. If you have in mind (what we call on Cisco devices) the remote span, i.e. one
device
doing a port copy from own of its own port to a port to a remote device, then
the observation point is an interface the packets are copied to.

So what's in comon between 1. and 2., the interface.

3. Now, if you mean that you do packet sampling in one interface and send
the results to another device (or observation domain), this is something which for
me is not feasable,
at least in my mind. Because the sampling function is part of metering process.
So observation point is actually where you sample.
Note: the sample mechanism part (or not) of the metering process is a principle we
should agree before
going much further. This concept must be part of the requirement document.
Now, I'm trying to imagine one application where your scenario would be
usefull....
A router composed of linecard 1 and linecard 2. We have 2 observation domains, 2
metering processes (one per line card).
The packets observed on an interface of linecard1 would be sampled, but not
exported to the collector. Instead they would be sent to the linecard 2 for latter
processing with the flow locally seen. That's right that you could possibly do
some more aggregations on line card 2... but do you have something specific in
mind? Because I see one drawback here: the IPFIX flow records have to be processed
twice within the router: once a "local export" to another observation domain, then
the "real" export. And as you know, this costs in terms of CPU.

> information export process.

I understand you concern and see my definition is not too clear.

In my mind, the metering process (on an observation point) will take care of
sampling (if configured), creating flows AND exporting. But it doesn't mean that
all of function must be enable; for example, you can create flows, observe them on
the router and not exporting, just to quickly detect and block a DOS attack.
NOTE: metering process composed or not of (sampling + flow creation + exporting)
is something else we should quickly/clearly define in our definition, after a
group agreement.

Justification: why does the metering process also contain the export function?
Again the example of a router composed of linecard 1 and linecard 2. We have 2
observation domains, 2 metering processes (one per line card). If the metering
process on linecard 1 wants to export flow, it should according to your view,
export first the flow to the router main board, which in turn will export it. You
will use the CPU on the Line card 1 AND on the main board. Not very efficient with
distributed system. And keep in mind that the main board will, according to your
view, have to process the export flow records from all the line card. This looks
like a perfect bottle neck!
But by having the metering process also exporting, you will have a sequence ID per
observation domain. This is an extra advantage. So if you miss flow records from a
specific line card (because of CPU/memory constraints), you know that the other
line card flow records are intact. And you can concentrate on the troubleshooting
of just one line card.

> exporter - meter - observation point

Yes, that's it for the high level view.
But as expressed above, the exporter is composed of one or more metering process,
actually one per observation domain. And the exporter doesn't take care of the
real flow records export which is defined part of the metering process.
Now, whether to call it meter or observation domain, I looks to me than
observation domain is more obvious but this is really a small detail.

So based on an email from Ganesh on the same thread,
Ganesh>Another point to note is that in draft-gsadasiv-ipfix-proposal-00.txt,
Ganesh>we have made meter to observation point 1 to 1.
a high level view would be:

+------------------------------------------------------------------------------------+

|
Exporter                                              |
|
+---------------------------------------------------------------------+         |
|       |                    Observation Domain   1
|          |
|       |
+----------------------------+                            |          |
|       |                    |       Metering  Process
|                            |          |
|       |
+----------------------------+                            |          |
|       |
^                                             |          |
|       |
|                                              |          |
|       |
+--------+---------+                                |          |
|       |                           |
|                                 |          |
|       |                          v
v                                 |          |
|       |                +--------------+
+--------------+                     |          |
|       |                |Obsv Point 1|   ..  |Obsv Point k|
|          |
|       |               +---------------+
+--------------+                     |         |
|
+---------------------------------------------------------------------+         |
|
....                                                           |
|
+---------------------------------------------------------------------+         |
|       |                    Observation Domain  L
|          |
|       |
+----------------------------+                            |          |
|       |                    |       Metering  Process
|                            |          |
|       |
+----------------------------+                            |          |
|       |
^                                             |          |
|       |
|                                              |          |
|       |
+--------+---------+                                |          |
|       |                           |
|                                 |          |
|       |                          v
v                                 |          |
|       |                +--------------+
+--------------+                     |          |
|       |                |Obsv Point 1|   ..  |Obsv Point k|
|          |
|       |               +---------------+
+--------------+                     |         |
|
+---------------------------------------------------------------------+
|
|+-------------------------------------------------------------------------------------+

> and then renaming all data collectors into collectors?

Fair enough.

Regards, Benoit

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Feb 2002 16:22:49 +0100

Hi Benoit,

> If you still have problem, we can try to find another way to express it.

I think I am a bit confused by the word "matches" in your last sentence.
The functions are already a kind of machting functions. Now the last sentence
says that a packet belongs to a flow where it matches all matching functions.

What about "A packet is defined to belong to a flow if it the defined
are evaluated successfully / evaluate to 'true' / are met / ... something
like that.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Feb 2002 16:33:49 +0100

--On 12 February 2002 07:37 -0800 Ganesh Sadasivan <[email-masked]> wrote:

> instead of matches a better wording would be "completely satisfies".
> Ganesh

Yes, much better.

    Juergen

> Juergen Quittek wrote:

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 12 Feb 2002 07:37:40 -0800

---

From: "Peter Phaal" <[email-masked]>
Date: Tue, 12 Feb 2002 10:29:37 -0800

> the "real" export. And as you know, this costs in terms of CPU.

There are a number of situations in which it would be nice to use IPFIX to
aggregate and export flow records based on remote sampling.
1. sFlow <http://www.sflow.org> sends packet samples to a remote collector
for aggregation. IPFIX would be a good way of exporting data from the
aggregator. sFlow is supported across the Foundry Networks product line.
2. The PSAMP http://www.research.att.com/~duffield/psamp/ group are
proposing to remotely export packet sampling. Again a remote aggregator of
PSAMP data might want to export aggregates using IPFIX.
3. Juniper sampled mirroring can remotely forward samples.

I assume that in each of these cases the IPFIX exporter is acting as a
"middle box."

Another situation would be a middle box that bridges netflow, LFAP or any
other existing flow record into IPFIX flow records.

Finally, a middle box aggregating IPFIX data from multiple IPFIX sources may
want to re-export aggregates (possibly removing duplicate flows).

I was looking through the drafts and it wasn't apparent to me how a middle
box would export flows on behalf of other devices (indicating the true
source of the data, and the scope of aggregation).

Presumably one would need to add an entry in 5.1 in the Data Model:

5.1.x MEASUREMENT ORIGIN
The IP address associated with the original measurement point. This may be
the same address as the exporter, or it may refer to a remote device that
provided the data. If flows are aggregated across multiple sources this
could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each
MEASUREMENT ORIGIN.

A corresponding adjustement to the Architecture document would also be
required, perhaps showing that collectors can also export IPFIX.

Peter
----------------------
Peter Phaal
InMon Corp.

[email-masked]

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 12 Feb 2002 19:48:21 +0100

Hi Peter,

Peter Phaal schrieb:
[...]
> could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each

Quoting from the draft section 5.1:

"The measuring device MUST be able to report the following attributes
 for each measured flow:
     [...]
     18. unique identifier of the observation point
     19. unique identifier of the measuring device
"

Is that not what you want?

> required, perhaps showing that collectors can also export IPFIX.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287 
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: "Peter Phaal" <[email-masked]>
Date: Tue, 12 Feb 2002 12:15:42 -0800

> Is that not what you want?

I didn't see this language in the posted drafts
<http://ipfix.doit.wisc.edu/archive/0541.html>.

This might be sufficient if the design document supports multiple
definitions of an observation point:
1. ifIndex|vlan ... (implies an observation point on measuring device).
2. Agent.<ifIndex|vlan...> (implies remote observation point on Agent)
3. Agent (all interfaces an remote Agent).
4. list of observation points (data aggregated from multiple observation
points).

An intermediate device collecting netflow, IPFIX, samples from multiple
sources requires a degree of flexibility in describing the source of the
data for each "virtual" or "proxy" observation point it re-exports using
IPFIX.

Is this type of measurement device within the scope IPFIX? Supporting
multi-tiered IPFIX architectures would make for much greater scalability. My
reading of the current architecture is that it limits itself to two or three
tiers (depending on how one counts). It's not clear that an observation
point could be an IPFIX collector, or that a collector could export IPFIX
data.

Peter
----------------------
Peter Phaal
InMon Corp.

[email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Wed, 13 Feb 2002 01:01:26 +0100

Peter

> 4. list of observation points (data aggregated from multiple observation

I would like to encourage you to review
http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt
It might solve your problem because we export:
    5.3.2  Case B, Template for Method Description
   This case describes the format for exported  configuration
   information. Each of the configuration templates within this flowset
   describes :
     * List of methods that define the Selection Criteria and the
       parameters for each method.
     * Observation Point and its description
  ...

Note that we assume in the draft that one observation point is interface or a
set of interface.

Now, the only thing which is missing in our draft is the unique identifier of
the measuring device (i.e. the exporter IP address) in the information model.
Because I was thinking that this unique ID would have been the source IP address
of the export packet (OK, it could be a loopback to be independent of the router
outgoing interface).
But I understand your point, and it's not a problem to add the unique identifier
of the measuring device (i.e. the exporter IP address) in the information model

> point could be an IPFIX collector, or that a collector could export IPFIX

I don't see why we should limit the IPFIX effort, as long as this is a MAY
feature.
This is a good point to clarify.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 13 Feb 2002 01:14:22 +0100

Peter,

> aggregate and export flow records based on remote sampling.

Agreed with the 3 examples below. But In these 3 examples, you export to a
remote collector.
I thought that Juergen wanted to export to another meter of the same exporter.
Hence my example with the export from line card 1 to line card 2, which doesn't
make sense to me.
More in the next email.

Regards, Benoit

---

From: "Peter Phaal" <[email-masked]>
Date: Tue, 12 Feb 2002 16:31:38 -0800

> of the measuring device (i.e. the exporter IP address) in the

Adding the unique identifier of the measuring device to the data model would
be a good idea.

NetFlow doesn't include the agent address as part of the NetFlow header,
forcing intermediate services (such as NetFlow replication) to spoof IP
source addresses to match that of the router. It's much cleaner if the flow
records are self contained and don't depend on lower protocol layers for
context.

You might consider the SMON MIB (RFC 2613) SmonDataSource when defining the
types of sources allowed. In addition to ifIndex, it identifies VLANs and
objects from the entity MIB as possible observation points.

Peter
----------------------
Peter Phaal
InMon Corp.

[email-masked]

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 13 Feb 2002 10:24:40 +0100

Hi Peter,

> <http://ipfix.doit.wisc.edu/archive/0541.html>.

Please look at http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt.
This is the current requirements draft and I was thinking you were
talking about it because your post did go to ipfix-req.
 
> point could be an IPFIX collector, or that a collector could export IPFIX

I like your proposal of building hierarchies of something like aggregators+
exporters for scalability. I think this should be considered in the architecture
draft. 

Sebastian

---

From: [email-masked]
Date: Wed, 13 Feb 2002 08:44:57 -0500

> records are self contained and don't depend on lower protocol layers for

	Having an exporter ID seems straight forward enough.
	How about text like this (FYI - hacked from LFAP spec)

Source Observation Address IE

   Source Observation address is the address of the device which
   observed the flow. This information is used by applications 
   to later correlate the ingress/egress port with a specific
Observation
   point. It is also used to  maintain the observation information when 
   there is an intermediate proxy. For example, given the picture below:
   
            SW1 --------    P1 ------ Collector
                            ^
                            |
            SW2----------   |
   
   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector like the same connection. With this IE in the message
   the original Observation point address is maintained.

---

From: Tanja Zseby <[email-masked]>
Date: Thu, 14 Feb 2002 12:24:27 +0100

Hi Jürgen and others,

In order to prevent mixing up the devices and the processes that run on 
the devices I would suggest to define the components it in the following 
way.
- Keep the definition of  the metering process as suggested in 2.4 by Jürgen
- Rename 2.6 (exporter) into exporting process
- Define the exporter as the device on which one (or more) metering 
processes and at least one exporting process run.
There can be meters that do not run an exporting process but exporters 
without metering process would not make sense. Therefore I prefer to use 
the term exporter for the device on which both processes run (metering 
and exporting) and distinguish it from a meter which can be defined as a 
device that runs only metering processes. So you can see an exporter as 
a meter device that additonally runs a flow exporting process.
Furthermore I agree with Benoit that sampling should be seen as part of 
the metering process. .

Regards
Tanja

[email-masked] wrote:

>>>Help        mailto:[email-masked] and say "help" in
>>>
>>message body
>>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------