Subject: [ipfix-arch] draft-gsadasiv-ipfix-proposal-00.txt

From: Mark Fullmer <[email-masked]>
Date: Tue, 12 Feb 2002 12:46:52 -0500

A few comments on draft-gsadasiv-ipfix-proposal-00.txt.  This made it to
a few people but the list bounced the address I originally sent from

     * Flow Header: Every flow export packet includes a flow header
       which carries some general information about the exporter, packet
       identification etc.

###
Using the export "packet" term too soon, ie if this is a TCP control
connection the packet may be partial.

   defined as a set of packets passing an observation point in the
   network during a certain time interval. All packets belonging to a
   particular flow have a set of common properties.  Each property is
   defined as the result of applying a function to the values of:

     a. one or more of packet header fields (eg. destination IP address)
     b. one or more properties of the packet itself (eg. packet length)
     c. one or more of fields derived from packet treatment (eg. AS
        number)

###
This implies that if an IP address:AS mapping changes then there
would be a new flow if additional packets are are received from the 
original IP.  This needs clarification.  An implementation may choose to
do the AS and potentially other accounting fields lookup during the export
phase.

   A packet is defined to belong to a flow if it matches all the defined
   properties of the flow. Flows can be defined in multiple ways. Some
   examples are:
   Example 1:
   To create flows, we define the different fields to distinguish flows.
   The different combination of the field values creates unique flows.
   If the keys are defined as {source IP address, destination IP
   address, TOS}, then all of

###
This is misleading, flow state is created by traffic, not by defining them.
It would be interesting to see multicast flow state created by the 
multicast routing protocols instead of traffic, I'll get to this in a 
different message.

   pass the observation point, in order to select only certain flows.
   The filter is defined by choosing fixed values for specific fields
   from the packet.

   All the packets that go from a customer network 192.1.40.0/24 to
   another customer network 171.6.23.0/24 with TOS value of 4 define a
   flow. All other combinations don't define a flow and are not taken
   into account. The 3 flows from example 2 would now be reduced to 1
   flow, by filtering away the second and the third flow.
   {192.1.40.0/24, 171.6.23.0/24, 4}.

###
I think we need some crude ascii art here.

               packets from observation point
                         ||
                         ||
                         \/
                      sampling
                         ||
                         ||
                         \/
                      filtering
                         ||
                         ||
                         \/
                    translations
                         ||
                         ||
                         \/
                    flow-engine
                         ||
                         ||
                         \/
              filtering of potential exports
                         ||
                         ||
                         \/
                    export-queue
                         ||
                       IPFIX
                         ||
                         \/
                      collector

Above the flow-engine can be considered the metering process and below
it the IPFX protocol.

flow-engine could be expanded to include bidirectional and aggregation
explanations.

2.2. Unidirectional and Bidirectional Flows

   A flow defined by the above terms is unidirectional. In case the
   exporter has got the knowledge of the bi-directional flows and in
   case the bi-directional information make sense, the exporter MAY
   choose to export in the same Template/Flow Record, along with
   bidirectional accounting information. This would save some bandwidth
   as the exporter won't have to send two unidirectional flow records.

###
You're referencing Template and Flow Record before defining them.

   is recomended that the flow record carry the Observation Point
   information along with the flow records when exported. In cases where
   there is a single observation point or where the observation point
   information is not relevant, the exporter MAY choose not to add this
   to the flow records.

###
Record or Header.  This may be too detailed verbage here since the export
process is not detailed until later.

3.2.2. Sampling packets on a flow type (Si)

   Packets that satisfy the sampling criteria for this flow type.
   Example:
   Sample every 100th packet that was received at an observation point
   and collect the flow information for a particular flow type. Choosing
   all the packets is a special case where sampling rate is 1:1.

###
Need to use consistent wording when describing the maintenance of flow
state.  'collect' is used here.

3.3. Selection Criteria of flows for export

   The measurement device MAY define additional rules so that only
   certain flows records are picked up for export. This MAY be done by
   either one of the two types of methods defined in 2.3.1 and 2.3.2 or
   a combination of them.

   Example:
   The flow records which meets the following selection criteria are

###
You're talking about exporting before defining what the export is.  Need
to establish relationship between flow state expiration and export first.

4. Flow Export Protocol

   The information that needs to be exported from the exporter can be
   classified into the following categories:
     * Control Information - This includes the flow type definition,
       selection criteria for packets within the flow. This is also
       called as control stream.

###
This is implying you're sending things like ACL's that define the
filters?  Good luck getting the group to agree on a standard format
for ACL's :)

   multicast group, instead of sending several unicast streams towards
   the different collectors. Multicast would lower the bandwidth
   requirements on the export link in case that the collectors are on
   the same media, and could lower the internal bus utilization on the
   exporter. Using multicast session with more than one collector
   joining the flow export multicast group, redundancy of collectors can
   be easily achieved.

###
Add some verbage about Multicast and security issues.  Anyone can 
join group, etc.

   secondary and a priority assigned to them.  The primary collector
   crash is detected at the exporter by the break in control connection
   (depending on the transport protocol the connection timeout
   mechanisms differ). On detecting loss of connectivity, the exporter
   opens data stream with the secondary collector of the next highest
   priority. This collector now becomes the primary. The maximum export
   data loss would be the amount of data exported in the time between
   when the loss of connectivity to the collector happened, and the time
   at which this was detected by the exporter.

###
Why is the separate control channel optional.  Why not just define it
and make it TCP?  It simplifies a bunch of other things later on.

When using TCP a procedure must be defined if the collector can not
decode the packet (ie garbled TCP stream).  For example reset the
connection.

The control connection should include a simple authenticator like a shared
secret so the collector can have some confidence it's a valid exporter.

   Sequence Number:
   Exporter generated number which uniquely identifies a packet.  The
   sequence number increments for subsequent export packets.  A separate
   sequence number is manintained for control and export data packets if
   control and data are send in separate packets.

###
In the current NetFlow export implementation the sequence number is 
per flow so the collector can calculate lost flows.  With per packet
sequence number this functionality is lost.  Mixing in control information
complicates it even more (did you lose a control packet or flow packet).

   Source ID:
   Unique identifier per observation domain.

###
There needs to be an exporter ID (IP address) so that replicated IPFX 
packets retain the exporter.  I'd like to see the Source ID restricted
to 16 bits so the collector doesn't need to maintain a hash table to
track the sequence numbers per exporter.

5.2. Template and Template Flowsets

   Templates are used to completely identify the structure and semantics
   of a particular information that needs to be communicated from the
   exporter to the collector. Each template is uniquely identified by a
   Template ID. The Template ID is a 16 bit identifier. A block of
   templates from <0-255> are reserved for sending some of the control
   information.  The rest of the template IDs can be used by the
   exporter to define the templates for the various flow types defined
   within the exporter. A Template within an export packet is called as
   a template record. A Template Flowset is a collection of one or more
   template records which have been grouped together in an export
   packet. The Flowset ID of a template flowset maps to a particular
   template format.

###
Your template explanation took a while to digest.  How about including
some common terminology like Type Length Value, ie the Template 
is the Type and Length, the flow records are the Values.

5.3.1. Case A, Template for Flow Record Definition

   The common examples of this case are templates for exported flow
   records, and templates for flow related statistics or errors in the
   exporter. Example of statistics information: total numbers of flows.
   The format of the Template Flowset for this case is described below:

###
Need common terminology again.  Statistics or Accounting?

5.4. Template Export Management

   The exporter takes the following steps for template export:

     * Periodically sends the entire template information and
       configuration information to the collector. This corresponds to
       the set of all Template IDs along with their descriptions and the
       set of all Observation IDs along with their descriptions. The
       periodic export frequency SHOULD be configurable in the exporter.

###
If the control connection is required this can go away.

   The format of the Data Flowset is described below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    FlowSet ID = Template ID   |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Record 1 - Field Value 3    |             ...               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Record 2 - Field Value 3    |             ...               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Record 3 - Field Value 1    |             ...               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

###
Verbage needs to be added about alignment.  u_int32's on 32 bit
boundries, u_in16's on on 16 bit boundries, etc.  This also implies
needing a 'NULL' field type for padding.  Need to define byte order
of fields.

Also the exporter SHOULD provide optimal encoding, ie
  u_int32
  u_int16
  u_int16
  u_int8
  u_int8
  u_int8
  u_int8

not
  u_int8
  pad
  pad
  pad
  u_int32
  u_int8
  pad
  pad
  pad
  u_int16
  u_int8
  pad
  u_int16
  u_int8
  pad

   In case the exporter is doing NAT [3] and in case the observation
   domain has got the knowledge of both inside and outside parameters,
   the exporter MAY choose to export both inside and outside parameters
   in the same Template/Flow Record (The NAT parameters being the IP
   address and/or the UDP/TCP ports). If not the exporter will only
   export the parameters observed at the observation point.

###
s/got//

   IPV4_SRC_ADDR                8       4     Source IPv4 Address

   SRC_MASK                     9       1     source route's mask bits

###
IPV4_SRC_MASK, be consistent

   INPUT_SNMP                   10      2     Input interface index

###
just call it ifIndex

                                              TCP/UDP destination port
   L4_DST_PORT                  11      2     number (.e.g, FTP, Telnet,
                                              etc...)

   IPV4_DST_ADDR                12      4     Destination IPv4 Address

   DST_MASK                     13      1     destination route's mask
###
ditto
                                              Bits

   OUTPUT_SNMP                  14      2     Output interface index
###
ditto

   IPV4_NEXT_HOP                15      4     Next hop router's IPv4
                                              Address

   SRC_AS                       16      4     Source BGP Autonomous
###
Unicast source AS.  Remember we have a multicast RIB too.  Maybe for
multicast it's the multicast source AS (they should be the same)

   DST_AS                       17      4     Destination BGP Autonomous
                                              System Number

   IN_BYTES_64                  23      8     64-bit counter for bytes
                                              associated with an IP Flow

   IN_PKTS_64                   24      8     64-bit counter for packets
                                              associated with an IP Flow

###
what about IN_*_32?

   FLOW_LABEL                   31      2     IPV6 Flow Label
###
IPV6_

                                              packets are sampled. For
   SAMPLING_INTERVAL            34      1     example, a value of 100
                                              indicates that one of
                                              every hundred packets is
                                              sampled.

###
This looks too restrictive, need at least 2 bytes, ie what about 1/1000

###
Juniper also has a run length

                                              The type of algorithm used
                                              for sampling data.
                                              Currently, the only
                                              sampling algorithm defined
   SAMPLING_ALGO                35      1     is:
                                              0x02 packet-sampling

                                              Timeout value for active
   FLOW_ACTIVE_TIMEOUT          36      2     flow entries in the
                                              cache.

                                              Timeout value for inactive
   FLOW_INACTIVE_TIMEOUT        37      2     flow entries in the
                                              cache.
###
This looks like control channel information.  Should indicate this.

8. The Collector Side

   The collector SHOULD receive template definitions from the exporter,
   before receiving flow records. The flow records can then be decoded
   and stored locally on the collector. In case the template definitions
   have not been received at the time a Flow Record is received, the
   collector SHOULD keep the Flow Record for later decoding when the
   template definitions will be received. The collector MUST decode and
   store the entire flow records, even if the semantics of one or more
   of the field types in the template associated with the flow record is
   not understood.

###
The "MUST decode and store" the entire flow record should be dropped.  The
collector may decide to only store some of the fields.  It may also 
decide to add fields of its own, for example exporter source.

mark

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