Subject: [ipfix] extensibility of the ipfix protocol

From: Sebastian Zander <[email-masked]>
Date: Wed, 07 May 2003 03:55:19 +0200

Hi,

although extensibility is mandatory by the requirements there hasn't
been a lot discussion on how to do it and the chosen candidate protocol
doesn't say much about extensibility. So here are my thoughts about
extensibility.

The protocol specification must define how the protocol can be extended.

I see the following (but there may be more) ways of extending the
protocol:

1. Extending the fixed packet header
This would allow to add new header fields without changing the
protocol specification.

A bit (X) could be stolen from version to indicate the presence of
extension header(s). Extension header(s) follow the fixed header if
X=1. Extension header(s) consists of type, length and value.

2. Extending the attribute/field space
This is certainly needed. It could be done at least in two ways:
a) A flat number space where numbers are specified in extension
    RFCs and registered by IANA. A nice thing would a dynamic
    space where numbers are not defined by IANA but could be negotiated
    out of band (see payload type in the RTP specification). Such a
    space could also be used as safe playground.
b) A number space which is defined in extension RFCs (IANA) and the
    possibility of using vendor specific attributes by having an optional
    vendor ID field in the template specification. The vendor ID would
    be IANA assigned but the vendor then could use its private field ID
    space (see the Diameter Base protocol specification). Adds more
    complexity and overhead to the protocol but could be very useful
    when the protocol becomes widely adopted and a lot of extensions
    are done.

3. Extending the type space (if there are types at all)
Probably there won't be much need to extent this because the protocol
specification could do a good job of specifying all the basic types.
If this really needs to be extended it would be probably done with a
revised protocol specification.

Comments? Opinions?

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander

--
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: Mark Fullmer <[email-masked]>
Date: Tue, 6 May 2003 23:46:27 -0400

One way to look at NetFlow v9 is a fixed header + TLV's.

Type           Definition
-----------------------------
0              Flowset
1              Options flowset
2..255         undefined
256 .. 65535   data templates defined by 0 or 1 

This should address (1), although the protocol document needs verbage.

You could also just use the existing options template mechanism.

I would like to see the number space used a little differently so a bit
(high bit, low bit, whatever) can be set that informs the collector what
to do if it can't decode the new option -- ignore it and move on or
give up.

(2)
I don't see where the flat space of 65534 attributes is going to be
a problem.  This would need to be partitioned into a well known,
reserved for future use, and reserved for vendor playground.  NetFlow
prior to v9 had 31 unique attributes.

(3)
Still up for debate if this shows up in the protocol.

mark

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 7 May 2003 00:51:20 -0400

One of the reasons behind extensibility was to make the protocol more
reliable (or open to reliability extensions...).

I guess we need to explain how having more types will help that.
----- Original Message -----
From: "Mark Fullmer" <[email-masked]>
To: "Sebastian Zander" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 06, 2003 11:46 PM
Subject: Re: [ipfix] extensibility of the ipfix protocol

> > D-10589 Berlin, Germany
www.fokus.fraunhofer.de/usr/sebastian.zander

---

From: Alex Audu <[email-masked]>
Date: Wed, 07 May 2003 10:25:14 -0500

Extensions should also allow a vendor to implement unique features not
ordinarily supported by the protocol specifications. This is useful for
differentiation.

One way to achieve this in the case of NetFlow v9 is to add an optional
Extension FlowSet to the generic Export Packet structure. All the type
definitions necessary to decode extension flow data will be specified here.
It may even be in plain TLV format, or any other formats preferred
by the vendor.

Regards,
Alex..