Subject: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions

From: Brian Trammell <[email-masked]>
Date: Mon, 3 Jul 2006 09:04:01 -0400

I have the following last-call comments for the Information Model.

In the -12 revision if the Information Model, we have:

>> Template ID:
>>     An identifier of a Template that is unique within the
>>      communication between an Exporting Process and a Collecting
>>      Process.  Typically, this Information Element is used for  
>> limiting
>>      the scope of other Information Elements.  Note that after a re-
>>      start of the Exporting Process Template identifiers may be re-
>>      assigned.

This scoping is still not quite right, as it limits the ability for a  
device exporting messages from multiple Observation Domains to use  
different template namespaces for each Domain; specifically, it  
unnecessarily breaks conceptual compatibility with the model  
presently used for multiple-domain export in V9.

That said, templates _should_ be unique to the session (or, here, the  
communication between EP and CP). They should just be unique to the  
session through the odId; so odId will have to be session scoped.

The following replacements for sections 5.1.8 and 5.1.9 in INFO 12  
will make this the case:

in IPFIX-INFO -12 (starting on Page 21):
5.1.8.  templateId
    Description:
       An identifier of a Template that is unique within an Observation
       Domain, that is, scoped to the Observation Domain ID of the
       containing IPFIX Message. Typically, this Information Element
       is used for limiting the scope of other Information Elements.
       Note that after a restart of the communication between the
       Exporting Process and Collecting Process, Template identifiers
       may be reassigned; this information element SHOULD therefore not
       be used by the Collecting Process as a persistent identifier.
    Abstract Data Type: unsigned16
    Data Type Semantics: identifier
    ElementId: 145
    Status: current

5.1.9.  observationDomainId
    Description:
       An identifier of an Observation Domain that is unique within
       the communication between the Exporting Process and Collecting
       Process. This identifier SHOULD also be unique per Exporting
       Process and per IPFIX Device; it is assumed that Observation
       Domains will be assigned identifiers according to the
       configuration of each IPFIX Device. Typically, this Information
       Element is used for limiting the scope of other Information
       Elements.
    Abstract Data Type: unsigned32
    Data Type Semantics: identifier
    ElementId: 149
    Status: current

Since templateID and observationDomainID are information element  
versions of protocol header fields, we'd also have to make the  
following changes to PROTO 22 to keep the documents parallel:

3.1 Message Header Format
<snip to middle of page 13>
    Observation Domain ID
            A 32-bit identifier of the Observation Domain that is
            locally unique to the communication between the Exporting
            Process and the Collecting Process.  The Exporting
            Process uses the Observation Domain ID to uniquely identify
            to the Collecting Process the Observation Domain that
            metered the Flows.  This identifier SHOULD also be unique
            per Exporting Process and per IPFIX Device; it is assumed  
that
            Observation Domains will be assigned identifiers according
            to the configuration of each IPFIX Device. The Observation
            Domain ID SHOULD be 0 when no specific Observation Domain
            ID is relevant for the entire IPFIX Message; for example,
            when exporting the Exporting Process Statistics, or in case
            of hierarchy of Collector when aggregated data records are
            exported.

3.4.1 Template Record Format
<snip to top of page 18>
      Template ID
          Each Template Record has a Template ID that is locally unique
          to the Observation Domain ID of the message in which the
          Template is exported. Template IDs 0-255 are reserved for
          Template Sets, Options Template Sets, and other reserved Sets
          yet to be created.  Template IDs of Data Sets are numbered
          from 256 to 65535.  There are no constraints regarding the
          order of Template ID allocation.

Thoughts and comments?

Thanks,

Brian

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 04 Jul 2006 16:58:14 +0100

Brian Trammell wrote:
>>>      Process.  Typically, this Information Element is used for limiting
> unnecessarily breaks conceptual compatibility with the model presently 
> used for multiple-domain export in V9.

Absolutely, this is subtly  different from current implementations of
distributed v9 exporters but has important implications.  The suggested
scoping would require that distributed parts of an exporter in different
observation domains communicate with each other to co-ordinate templates
and other information.

Note that this is a change from what we originally had and in the
Protocol we still have:
  "Template IDs are unique per Exporting Process and per Observation 
   Domain." - IPFIX Protocol Specification, section 9, page 36.

At the moment there is no way for a Collector to identify an individual
Exporting Process, but it can identify a session.

> session through the odId; so odId will have to be session scoped.

I agree completely.  Although UDP sessions are hard to define, on a
restart the Exporting Process will resend all the templates etc.

> The following replacements for sections 5.1.8 and 5.1.9 in INFO 12 will 
> make this the case:
> 
> versions of protocol header fields, we'd also have to make the following 
> changes to PROTO 22 to keep the documents parallel:
> 
>            per Exporting Process and per IPFIX Device; it is assumed that

I agree with these definitions and scoping and I think we need them to
avoid adding unnecessary overhead to distributed implementations.

I also think that we cannot scope anything to the Exporting Process as
we don't have a way for a Collector to identify the Exporting Process.
Note, even using the Exporting Process ID there isn't a mechanism for
an Exporting Process to communicate which Exporting Process ID it is.

Furthermore, using the ExportingIPv4Address and ExporterIPv6Address
is not sufficient to identify and Exporting Process as there may be
more than one Exporting Process within an IPFIX Device.

regards

Andrew

--
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/