Subject: RE: [ipfix-reqs] Flow definition

From: "Harrington, David" <[email-masked]>
Date: Mon, 23 Jun 2003 08:59:28 -0400

Hi,
 
I don't think MPLS flows are within the the scope of the charter.
 
dbh

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Friday, June 20, 2003 4:35 PM
To: [email-masked]
Subject: [ipfix-reqs] Flow definition

I was comapring the terminology used in requirements against 
architecture. The req spec defines flows as: 

"A flow is defined as a set of IP packets passing an observation point 
in the network during a certain time interval." 

The arch. spec just mentions it as "packets" and not "IP packets". 

The "IP packets" does not sound really correct if we are talking about 
defining flows based on MPLS too. An MPLS packet could encapsulate 
a non-IP packet and if one defines a flow based on just labels, then 
it beats the above definition. 

I have the following proposal: 
1. 
"A flow is defined as a set of IP packets or a sub-IP encapsulated IP 
packets passing 
an observation point in the network during a certain time interval." 
2. 
In the section on MPLS there should be  a statement telling that for 
MPLS packets, 
the  metering process has to dig into the packet or by some other means 
find out if the encapsulated packet is an IP packet. 

Any other suggestions? 

Thanks 
Ganesh 

-- 
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: Ganesh Sadasivan <[email-masked]>
Date: Mon, 23 Jun 2003 10:06:07 -0700

Thanks David. I re-read the charter & agree that the charter does
not mention about MPLS flows. But the question is if flow collection is
done on MPLS encapsulated IP packet ? If so should we not explicitly
include them in the flow definition.

-Ganesh

"Harrington, David" wrote:

>  Hi,I don't think MPLS flows are within the the scope of the
> charter.dbh
>

---

From: Ganesh Sadasivan <[email-masked]>
Date: Mon, 23 Jun 2003 15:35:50 -0700

Looks like there no definition for an IPFIX device in the reqs spec.
Shouldn't there be ?

Should there be definition for "Collector"  which is the receiving IPFIX

device in addition to "Collecting Process".

"Collector
The device which hosts one or more collecting processes."

Thanks
Ganesh

---

From: Simon Leinen <[email-masked]>
Date: Tue, 24 Jun 2003 10:00:34 +0200

Ganesh Sadasivan writes:
> not mention about MPLS flows. But the question is if flow collection
> is done on MPLS encapsulated IP packet ? If so should we not
> explicitly include them in the flow definition.

I would say no, we shouldn't.
-- 
Simon.

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 24 Jun 2003 18:55:10 -0700

Hi Nevil,

Nevil Brownlee wrote:

> Hi Simon:
> I've been working with Ganesh on editing the Architecture Draft.
> Seems to me that this is an issue which needs more discussion.
> Here's my thoughts on it:
>
>  - If a network element (switch or router) understands things
>    like MPLS, it makes sense to let it use that understanding
>    in creating flows.
>

Agreed.

>
>  - On the other hand, we have to define a 'base specification,'
>    i.e. what's the minimum set of packet attributes an IPFIX
>    exporter MUST support if it claims to be IPFIX-conformant?

The requirement spec talks about the minimal requirements.
But as you say, we need to have better definition in terms of
what gets supported in the case of GRE, IP-in-IP etc where
there could be the same fields (like IP address) in the multiple
encapsulated layers. This IMHO can go into the information
model.

>
>
>  - It's very difficult to decide where to draw the line on this.
>    MPLS is clear enough, but how about other encapsulations,
>    e.g. IP-in-IP, GRE, etc.?  Application information, e.g. in
>    RTP header fields [RFC1889], raises even more questions.
>

I am copying your suggested definition of flow which looks
fine to me:

"A 'flow' is a set of IP packets, or encapsulated
IP 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. "

>
> How about the following as a minimal definition for the header
> fields which can define a flow?  (This is one of three list items
> in the current Architecture Draft).

>
>
>  * One or more header fields of the actual packet, e.g. destination
>    IP address, or one of the fields in the packet's encapsulation
>    header, e.g. label for MPLS, tunnel end-points for IP-in-IP, etc.

Agreed.

>
>
> The IPFIX Information Model could specify encapsulation-header-based
> attributes as they seem neccessary and/or useful ...
>
> Also, another Architecture issue, the Architecture Draft (in its
> original versions) refers at various points to flow 'keys' and
> 'fields.'

While discussing the flow defintion sometime back we agreed upon to
use  the term flow 'keys' . Mainly because it was understood by all
folks who were participating in that discussion. I am ok using 'attributes'
or 'keys' but not both:)

> Although it's sensible to talk about 'fields' in the
> exported flow records, I feel it would be more sensible to use the
> term 'attributes' to refer to things used in defining flows, in all
> the IPFIX drafts.  That would mean that IPFIX was using the term
> 'flow attributes' in the same way as is done in RFCs 2720-2724 (RTFM)
> and 2924 (Accounting Attributes).  What do others think about this?
>
> Cheers, Nevil
>
> -----------------------------------------------------------------------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 24 Jun 2003 19:24:43 -0700

Hi,

    I added text to some of the unfilled section in the arch spec. Please
    comment .

Encoding Control Information

   The following rules provide guidelines to be followed while encoding
   the control information.

     - Per-flow control information SHOULD be encoded such that it can
       capture the structure and semantics of the corresponding flow
       data for each of the flows exported by the IPFIX device.
     - Configuration control information SHOULD be encoded such that it
       can capture the structure and semantics of the corresponding
       configuration data. The configuration data which is also control
       information, SHOULD carry additional information on the boundary
       within which the configuration takes effect. For example, sampling
       using the same sampling algorithm, say 1 in 100 packets is
       configured on 2 observation points O1 and O2. The configuration
       in this case MAY be encoded as <ID, boundary (O1,O2), sampling
       algorithm, interval (1 in 100)> where ID uniquely identifies this
       configuration.
     - There SHOULD be provisions to encode fixed length and variable
       length fields
     - Should we mention anything about the order in which fields are
       encoded, i.e. network order/host order?  [Nevil's suggestion: all
       fields MUST be encoded in network byte order]

 Encoding Flow Data Information

   The following rules provide guidelines to be followed while encoding
   the flow data information.

     - A flow data record SHOULD contain enough information so that the
       collecting process can identify the corresponding <Per-flow
       control information, Configuration control information>.

IPFIX Specific DoS attack

   There is a specific attack on the IPFIX portion of the IPFIX device
   or Collector.
     - The attacker could pound the  Collector with spoofed IPFIX export
       packets. One way to solve this problem is to periodically
       synchronize the sequence numbers of the flow records between
       exporting process and the collecting process.
     - The attacker could provide false reports to the IPFIX device by
       sending spoofed control packets.

   The problems mentioned above can be solved to a large extent if the
   control packets are encrypted both ways.

Thanks
Ganesh

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 25 Jun 2003 11:14:19 +1200

'fields.'  Although it's sensible to talk about 'fields' in the

Cheers, Nevil

---

From: Simon Leinen <[email-masked]>
Date: Thu, 26 Jun 2003 21:31:06 +0200

>  - If a network element (switch or router) understands things like
>    MPLS, it makes sense to let it use that understanding in creating
>    flows.

Maybe, but MPLS is just one of many possible encapsulations for IP
packets.  I don't think MPLS-specific attributes should be treated any
differently from e.g. attributes that are specific to ATM, Ethernet,
Frame Relay, POS.  This would be a somewhat open-ended endeavour, so
I'd like to keep this out of the base IPFIX standards.

Just defined MPLS-specific IPFIX attributes in a specific-lower-layer
extension to IPFIX.  There can be other extensions for Ethernet etc.

> fields which can define a flow?  (This is one of three list items in
> the current Architecture Draft).

> attributes as they seem neccessary and/or useful ...

Yes, but I suggest to keep specific lower layers out of the base
document set.
-- 
Simon.