Subject: semantics of multiple identical Information Elements in a template

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Mar 2006 14:54:52 -0500

Benoit,

Regarding multiple identical information elements, you proposed the  
following a couple of months ago:

> In section 8 "Template Management", after the following paragraph...
>
> If a specific Information Element is required by a Template but is  
> not available in observed packets, the Exporting Process MAY choose  
> to export Flow Records without this Information Element in a Data  
> Record defined by a new Template.
>
> I would add:
>
> If an Information Element is required more than once in Template,  
> the different occurrences of this Information Element SHOULD follow  
> the logical order of their treatments by the Metering Process. For  
> example, if a selected packet goes through two hash functions, and  
> if the two hash values are sent within a single template, the first  
> occurrence of the hash value should belong to the first hash  
> function in the Metering Process. For example, when exporting the  
> two source IP addresses of an IPv4 in IPv4 packets, the first  
> sourceIPv4Address Information Element occurrence should be the IPv4  
> address of the outer header, while the second occurrence should be  
> the inner header one.
>
> In section 9 "The Collecting Process's Side", at the very end, I  
> would add:
>      The Collector MUST support the use of Templates containing  
> multiple occurrences of
>      the similar Information Elements.
>
> Note: this text should solve the section 3.1.2.1 "Multiple IE of  
> same field type" open issue in draft-boschi-ipfix-implementation- 
> guidelines-00.txt Regards, Benoit.

I'm probably a bit late to the party on this, but yes, this seems  
exactly the right thing to do for IPFIX version 0x000A. However, I  
think we should be more explicit about the semantics implied by this  
approach, and more restrictive on the applicability of multiple  
information elements in order to avoid any grey areas that might be  
used by implementors to overload multiple IE support in mutually  
unintelligible ways.

Specifically, in investigating whether multiple information elements  
would be applicable for biflows -- exporting a forward direction  
counter in the first counter IE and a reverse direction counter in  
the second counter IE -- I realized you could argue that, because the  
reverse counters are related to the "second" direction seen at the  
Metering Process, you could use two IEs (say, octetTotalCount), have  
the first be the forward counter, the second be the reverse counter,  
and dispense with having to define any new information elements.

However, what would the limits be on this approach? Say I wanted to  
export forward and reverse non-key header fields, say,  
tcpSequenceNumber. Would this conflict with a Collecting Process  
expecting to receive data about some sort of (admittedly ill-advised)  
TCP-in-TCP tunneling scheme?

At this point I realized that overloading multiple IE support for the  
biflow case is probably not the right thing to do, at least with  
multiple IE support expressed as above. However, the language in the  
protocol document should make it explicit that only certain semantics  
are currently permitted with multiple identical information elements.

(As an aside, note that as this example is written, it _does_ obviate  
the need for all but one of the mplsLabelStackEntry IEs, since the  
label stack is "unwrapped" by the Metering Process in a defined order.)

Regards,

Brian