Dear Benoit and all,
The problem with this is that we want to have well defined selector
algorithms, right? So we register a number for each defined algorithm with
IANA and mandate a consistant description of the algorithm (propably as
RFC). So it gets difficult to have intermediate or vendor specific selector
algorithms! I would like to propose a solution for this. However it has the
drawback that it makes the definition and usage of vendor specific selector
algorithms easier and lifts the pressure of registering new algorithms with
IANA.
I would change the selectorAlgorithm Information Element from octet to
unsigned64. The content would be defined as follows:
6.2.3 selectorAlgorithm
Description:
Specifies the selector algorithm (e.g., filter, sampler, hash)
that was used on a packet. It is exported in the options data
flow record to specify how a collector has to interpret a data
flow record. The Information Element should be encoded in the
following way in an unsigned64 value:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Selector Algorithm Indentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The most significant bit must be set if the selector algorithm is
defined by an enterprise and is not registered with IANA. The
following 31 bits contain a Selector Algorithm Identifier. This
is the value registered with IANA if the enterprise bit E is not
set. Otherwise it depends on the Enterprise Number that is
encoded in the last 32 bits. The Enterprise Number is the same
as defined for Information Element templates. If the Enterprise
Bit E is not set the Information Element may be reduced to an
unsigned32 data type. If the size is not reduced then the
Enterprise number has to be set to 0.
The following Selector Algorithms Identifiers are currently
defined:
* 1 Systematic count-based sampling
* 2 Systematic time-based sampling
* 3 Random n-out-of-N sampling
* 4 Uniform probabilistic sampling
* 5 Non-uniform probabilistic sampling
* 6 Non-uniform flow state sampling
* 7 Match based filtering
* 8 Hash based filtering
* 9 Router state filtering
The parameters for most of these algorithms are defined in this
information model. Some parameters - especially those for
algorithms 5, 6 and 8 are not covered by this information model
since they depend very much on the underlying hardware.
Currently there are no hash functions defined.
EDITOR'S NOTE: This list may extend to the final version. The
"unsigned64" data type is probably not the best choice but keeps the
list extensible.
Abstract Data Type: unsigned64
Data Type Semantics: identifier
ElementId: 302
Status: current
The text may still be subject to changes if I expressed myself not clear
enough.
I hope that makes this element more flexible but still simple enough.
Best Regards,
Thomas
--
Thomas Dietz
Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany
> -----Original Message-----
> From: owner-psamp@ops.ietf.org
> [mailto:owner-psamp@ops.ietf.org] On Behalf Of Benoit Claise
> Sent: Monday, February 27, 2006 4:41 PM
> To: Juergen Quittek
> Cc: psamp
> Subject: Re: PSAMP IANA considerations section
>
> Juergen,
>
> This open issue should find a solution for the next version of the
> draft, to be published by Monday.
> See inline.
> > --On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote:
> >
> >> Dear all,
> >>
> >> Here is a proposal for the IANA considerations section.
> >>
> >>
> >> 1. 9. IANA Considerations
> >>
> >> The PSAMP Protocol, as set out in this document, has two sets of
> >> assigned numbers. Considerations for assigning them are
> discussed in
> >> this section, using the example policies as set out in the
> >> "Guidelines for IANA Considerations" document IANA-RFC
> >> [RFC2434].
> >>
> >> 9.1 IPFIX Related Considerations
> >>
> >> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA
> >> considerations section in [IPFIX-PROTO] for the assignments of
> >> numbers used in the protocol and for the numbers used in the
> >> information model.
> >>
> >> 9.2 PSAMP Related Considerations
> >>
> >> Each new selection method MUST be assigned a unique value for the
> >> selectorAlgorithm Information Element. Its configuration
> >> parameter(s), along with the way to report it/them with an Options
> >> Template, MUST be clearly specified.
> >>
> >> Each new selection method MUST be assigned a unique value for the
> >> selectorAlgorithm Information Element. New assignments
> for the PSAMP
> >> selection method will be administered by IANA, on a First
> Come First
> >> Served basis [RFC 2434], subject to Expert
> >> Review [RFC 2434], i.e. review by one of a group of experts
> >> designated by an IETF Operations and Management Area
> Director. The
> >> group of experts must double check the Information Elements
> >> definitions with already defined Information Elements for
> >> completeness, accuracy and redundancy. Those experts will
> initially
> >> be drawn from the Working Group Chairs and document editors of the
> >> IPFIX and PSAMP Working Groups.
> >>
> >> Now, two questions:
> >> 1. I'm not too sure whether we should mandate a new IETF
> RFC for the
> >> new selection method description?
> >
> > This would be a tough requirement. However, it would make
> sure that the
> > new methods is well documented.
> So the text proposal is fine with you, right?
> >
> >> 2. I'm not too sure whether we should mandate new IANA-registered
> >> information elements for the new selection method?
> >
> > Since we do not have vendor IDs in here, this is the only way of
> > achieving
> > interoperability.
> I had in mind that the selectorAlgorithm could be specified with the
> Entreprise Number, for proprietary purposes
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |E| Information Element ident. | Field Length
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Enterprise Number
> |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure G: Field Specifier format
>
>
> >
> >> In other words, can we have proprietary selection
> method in the
> >> selectorAlgorithm Information Element?
> >
> > Can't we assign an interval, say [1024 - ...] and declare selection
> > methods
> > with identifiers in that interval as 'experimental' or even
> > 'implementation specific'?
> Do we need this if we use a I.E. proprietary definition with the
> Entreprise Number?
>
> Don't forget that the selectorAlgorithm is specified as an octet.
>
> Regards, Benoit.
> >
> >> Regards, Benoit.
>
>
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature