Subject: [ipfix] Template ID scope in IPFIX protocol/architecture drafts

From: Gerhard Muenz <[email-masked]>
Date: Mon, 15 May 2006 15:25:59 +0200

Hi,

In both draft-ietf-ipfix-protocol-21 and
draft-ietf-ipfix-architecture-10 is written in the terminology section:

(1)
   * Template

      [...]  Each Template is uniquely identifiable by means
      of a Template ID.

In draft-ietf-ipfix-protocol-21, Section 8:

(2)
   A Template ID MUST be unique per Observation Domain. Different
   Observation Domains from the same Exporter may use the same Template
   ID value to refer to different Templates.

In draft-ietf-ipfix-protocol-21, Section 3.3:

(3)
   Observation Domain ID
           A 32-bit identifier of the Observation Domain that is
           locally unique to the Exporting Process.  The Exporting
           Process uses the Observation Domain ID to uniquely identify
           to the Collecting Process the Observation Domain that
           metered the Flows.  Collecting Processes SHOULD use the
           combination of the Exporter (exporterIPv4Address,
           exporterIPv6Address, or exportingProcessId) and the
           Observation Domain ID field to separate different export
           streams originating from the same Exporting Process. [...]

Am I right that the following statements are right?
1. Template IDs are locally unique per Observation Domain ID.
2. Observation Domain IDs are locally unique per Exporting Process.
3. An Exporting Process is uniquely identified by exporterIPv4Address,
exporterIPv6Address, or exportingProcessId.

In this case, (1) might be misleading since a Template is uniquely
identified by the 3-tuple (Template ID, Observation Domain ID,
exporterIPv4/6Address/ProcessId).

A related question:
If none of the fields exporterIPv4Address, exporterIPv6Address, or
exportingProcessId are exported, how do we identify the Exporting
Process? By the source IP address in the header of the IPFIX packet?

Another remark: sourceId still appears various times in the protocol
draft. Maybe it should be replaced by observation domain id.

Thanks for your answers.
Regard,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
EMail: [email-masked]
WWW:   http://net.informatik.uni-tuebingen.de/~muenz

---

From: Lutz Mark <[email-masked]>
Date: Mon, 15 May 2006 16:49:08 +0200

Hi Gerhard,

> 2. Observation Domain IDs are locally unique per Exporting Process.

yes.

> exporterIPv6Address, or exportingProcessId.

I would say that there is no way to uniquely identify an
exporting process. Since:
o the exportingProcessId is nothing to rely on.
   It is optional to export and has to be configured by hand.
o an exporting process can export via multiple source
   ip addresses
o an ipfix device can host multiple exporting processes

> Process? By the source IP address in the header of the IPFIX packet?

Templates IDs are unique per SCTP or TCP connection and
for UDP per ip source address and UDP port numbers.

Best regards,
Lutz

--
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: Brian Trammell <[email-masked]>
Date: Mon, 15 May 2006 10:08:20 -0400

Gerhard,

Replies inline.

> exporterIPv6Address, or exportingProcessId.

Yes.. at least this is how I interpret the intersection of -21  
section 8 and -21 section 3.3.

> exporterIPv4/6Address/ProcessId).

You're not alone in finding this misleading. I was initially quite  
confused by the inconsistency here -- the message that resulted from  
this confusion is in the list archive somewhere :)

> Process? By the source IP address in the header of the IPFIX packet?

I'd assumed that was the only way to handle it... Given that the  
exporter identifier is the root scope of the Observation Domain ID,  
which is itself the root scope of all other scopes including the  
Template ID required to interpret any exported data at all, does it  
even make sense to export the exporter identifier? If it's necessary  
to interpret Observation Domain IDs other than from IPFIX Message  
source IP address, then the exporter identifier _should_ probably  
appear in the message header.

Actually, we have another problem here. How should a collecting  
process determine the exporter IPv4 or IPv6 address on a multihomed  
SCTP association? Defining it as the IP source address is  
problematic, as the IP source address is not constant over the life  
of an association. The first thing that comes to mind is to define  
some rule for this situation (e.g., numerically lowest address). But  
this seems a bit hackish...

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 15 May 2006 11:33:16 -0400

> for UDP per ip source address and UDP port numbers.

Actually, wouldn't it be Observation Domain IDs that are unique per  
"session"? And multihomed collectors in the UDP case complicate this  
even further - you really have to look at the destination address,  
too, for UDP.

So it seems like the proper way to resolve this issue is to define a  
"Session" (as an SCTP association, TCP connection, or UDP four-tuple  
and timeout (ick!)), then define the Session to be the root scope,  
not the exporter identifier. So, Observation Domain IDs are unique  
within the Session, and all other scopes are unique within the  
Observation Domain ID.

Thoughts?

Brian

---

From: Lutz Mark <[email-masked]>
Date: Mon, 15 May 2006 17:12:29 +0200

> for UDP per ip source address and UDP port numbers.

Oops:
TemplatesID/ObservationDomainID-tuple is unique per SCTP or TCP
connection and for UDP per ip source address and UDP port numbers.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 15 May 2006 12:36:50 -0400

Gerhard,

The timeout would have to be a feature of UDP Sessions... since there  
is no "session" concept for UDP, without a timeout, no UDP four-tuple  
could ever be reused after Metering Process or Collecting Process  
restart, which is not workable.

(Personally, I think this is yet another argument against using UDP)

- Brian

On May 15, 2006, at 11:43 AM, Gerhard Muenz wrote:

> Brian,
> Brian Trammell wrote:
>> too,
>> for UDP.
>> "Session" (as an SCTP association, TCP connection, or UDP four- 
>> tuple and
>> timeout (ick!)), then define the Session to be the root scope, not  
>> the
>> exporter identifier. So, Observation Domain IDs are unique within the
>> Session, and all other scopes are unique within the Observation  
>> Domain ID.
>>
>> Thoughts?
>
> Ok, but without the timeout please. The timeout cannot be a  
> distinctive
> property of a session.
>
> Gerhard
>
>
> -- 
> Dipl.-Ing. Gerhard Münz

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 15 May 2006 17:43:30 +0200

Brian,

Brian Trammell wrote:
> even further - you really have to look at the destination address, too,
> for UDP.
> 
> "Session" (as an SCTP association, TCP connection, or UDP four-tuple and
> timeout (ick!)), then define the Session to be the root scope, not the
> Session, and all other scopes are unique within the Observation Domain ID.
> 
> Thoughts?

Ok, but without the timeout please. The timeout cannot be a distinctive
property of a session.

Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 May 2006 04:00:29 +0200

Gerhard,
> draft. Maybe it should be replaced by observation domain id.
Thanks. Corrected from sourceId to observationDomainId.

Regards, Benoit.