Subject: [ipfix-arch] [Fwd: [ipfix] Re: Information Model]

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 12 Feb 2002 15:17:52 -0800

Subject: Re: [ipfix] Re: Information Model
From: Ganesh Sadasivan <[email-masked]>
To: Mark Fullmer <[email-masked]>
Cc: Benoit Claise <[email-masked]>, [email-masked]
Date: Tue, 12 Feb 2002 15:14:11 -0800

Hi Mark,
  Thanks for the comments. See inline.
Ganesh

Mark Fullmer wrote:

> Comments start with ###
>
>
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>      * Metering Process: Measurement process that is carried out at the
>        observation domain.
>
>      * 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.

I do not understand.  This packet is generated at the level of exporter

>
>
> 2. Flow Type and Flow Definition
>
>    As defined in the requirement draft [1],
>      "A flow is 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 derived from the
>      data contained in the packet and from the packet treatment at the
>      observation point."
>
>    In this draft we define the flow more specifically.  A flow is
>    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.

Yes, if flow is AS based.

> An implementation may choose to
> do the AS and potentially other accounting fields lookup during the export
> phase.
>

There is the problem you mentioned above in such a case.

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

The "create" should probably be changed to something else. Yes flows
are created when a set of fields are designated the unique combination
of which identifies the flow.

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

??

>
>
>    Example 3:
>    To create flows, we can filter some field values on all packets that
>    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
>                          ||
>                         IPFX
>                          ||
>                          \/
>                       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.

There is the concept of observation domain to do the same. I drew up a
figure as response to Jurgene's mail on the thread "Terminology.  sggestion".
<cut>

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

Flow Record is defined in the Terminology section. "Template" is not
necessary here I guess.

>
>
> 3. Metering Process Functions
>
> 3.1. Flow Classification
>
>    The collector MUST be able to map the flow to the corresponding
>    property types defined by the flow type. This can be done only if the
>    collector has a mapping from flow type identifier (carried in each
>    flow record) to its actual structure. More details of how this can be
>    acheived is decribed in section 5.
>
>    In addition the collecter, when it receives the flow records, MAY
>    need the following interpreting the flow records furthur:
>
>      a. Observation Point.
>      b. Selection Criteria of Packets
>
>    As mentioned in section 2.1, a flow record can be better analyzed if
>    the Observation Point from which it is measured is known. As such it
>
> Sadasivan & Claise                                              [Page 7]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    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.

<cut>

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

Ok.

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

Does export need a more explicit definition than IPFIX?

<cut>

>
>
> 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 :)

Hoping to put in some basic elements (like sampling information etc)
and rest of it I guess would be propritery.

<cut>

>
> 4.1.2. Collector Redundancy
>
>    In case there are multiple collectors, the exporter MAY multicast the
>    flow records to the set of collectors that joined the export
>    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.

Ok.
<cut>

>
>
> 4.2.3. Collector Failover
>
>    This is an extension to section 4.2 to take care of collector crash.
>    The exporter opens control connections to multiple collectors. But
>    data gets sent only to one of the collectors which is chosen as the
>    primary. There could be one or more collectors configured as
>    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.

I agree with you that it simplifies. These are 2 models we are suggesting
which can be used for 2 different situations.

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

Ok.

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

You mean to say something like MD5?
<cut>

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

I thought it was per packet. Am I wrong? If so it is additional 4 byte info
per record? I thought there was a # of flow records in the header which
along with the sequence number in the header would give the count.

> 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).

>
>
> Sadasivan & Claise                                             [Page 13]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    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.

What do you mean by "replicated IPFX packets"?

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

Ok.

>
>
> 5.3. Categories of Template Flowset
>
>    As explained in the terminology section, a flowset is a collection of
>    records with a similar template format in an export packet. Flowset
>    ID shares the same number space as a template ID. Template ID <0-255>
>    are reserved as mentioned above and these are used by Flowset IDs to
>    send Template Flowsets of different formats. All of the Templates are
>    sent over the control stream. The different template formats being
>    used are:
>
> 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?

Statistics.

> 5.6. Exporting Flow Records
>
>    As mentioned above flow records can go through the same stream as a
>    control information or through a different stream as per the
>    description in section 4.1 and 4.2. If data stream is different, it
>    would be identified by a different sequence number. In anycase the
>    flags field of the flow export header MUST indicate that the packet
>    has only data flowsets (flag in the flow export header is set to
>    "data") or if it carries control and data flowsets (flag is set to
>    "both").  Data packets contain flow records corresponding to one or
>    more template IDs. Flow records that belong to the same template ID
>    can be grouped together to utilize the bandwidth better.  A
>    collection of one or more flow records that have have the same
>    template ID is termed as a Data Flowset. The Flowset ID of a data
>    flowset is assigned the Template ID to which all the records in this
>    data flowset belong to. The collector uses this Flowset ID to
>    interpret the data contained within the flow records. A data flowset
>    cannot be split across multiple flow record packets.
>
> ###
> When exporting the data via UDP there exporter MUST have a configuration
> option to limit the maximum packet size so that tunneled exports do
> not end up being fragmented.

agreed.

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

I guess over netwrok we have to send it as packed without any padding.
The exporter and collector may be running different processors.

>
>
> 5.6.1. Field Descriptions
>
>    FlowSet ID = Template ID
>    Template ID corresponding to the flow records in the flowset.
>
>    Length:
>    The length of the Data FlowSet including FlowSet ID and the Length .
>
>    Record N - Field N
>    The remainder of the Data FlowSet is a collection of field values.
>
> Sadasivan & Claise                                             [Page 22]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    The Type and Length of the fields have been previously defined in the
>    Template Record referenced by the FlowSet ID/Template ID.
>
>    The flow records contains the values for the fields defined by flow
>    type.
>
> 6. Specific Technology Considerations
>
> 6.1. Network Address and Port Translation
>
>    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//

Just one place - right?

>
>
>    This just implies that the information model MUST have inside and
>    outside parameters defined.
>
>    A NAT device can be installed between the exporter and the collector.
>    This means that the flow records IP address could be meaningless for
>    the data analyzis without a NAT translator on the collector's side.
>    This case is out of the scope of this document as it concerns the
>    analysis of the data and not the export.
>
> 7. Information Model
>
>    The information model for a flow measurement report is the list of
>    possible attributes of a flow, selection criteria (like parameters
>    for sampling) and observation point.  The table below described all
>    the field type definition that an IPFIX compliant exporter will
>    support:
>
>    Field Type                 Value   Length  Description
>
>    IN_BYTES_32                  1       4     32-bit counter for bytes
>                                               associated with an IP Flow
>
>    IN_PKTS_32                   2       4     32-bit counter for packets
>                                               associated with an IP Flow
>
>    FLOWS                        3       4     Number of main cache flows
>                                               that were aggregated
>
>    PROT                         4       1     IP protocol byte.
>
> Sadasivan & Claise                                             [Page 23]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    TOS                          5       1     Type of service byte
>
>    TCP_FLAGS                    6       1     TCP Flags (cumulative OR
>                                               of TCP flags)
>
>                                               TCP/UDP source port
>    L4_SRC_PORT                  7       2     number (.e.g, FTP, Telnet,
>                                               etc...)
>
>    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
>
>    BGP_NEXT_HOP                 18      4     Next-hop router in the BGP
>                                               domain
>
>    IPM_DPKTS                    19      4     Packet count for IP
>                                               Multicast
>
>    IPM_DOCTETS                  20      4     Octet (byte) count for IP
>                                               Multicast
>
>                                               SysUptime at which the
>    LAST_SWITCHED                21      4     last packet of this flow
>                                               was switched
>
> Sadasivan & Claise                                             [Page 24]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>                                               SysUptime at which the
>    FIRST_SWITCHED               22      4     first packet of this flow
>                                               was switched
>
>    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?
>
>    MAC_ADDR                     25      6     Layer 2 Media Access
>                                               Control address associated
>                                               with a flow
>
>    VLAN_ID                      26      2     Virtual LAN identifier
>                                               associated with a flow
>
>    IPV6_SRC_ADDR                27      16    IPv6 Source Address
>
>    IPV6_DST_ADDR                28      16    IPv6 Destination Address
>
>    IPV6_SRC_MASK                29      1     IPv6 Source Mask
>
>    IPV6_DST_MASK                30      1     IPv6 Destination Mask
>
>    FLOW_LABEL                   31      2     IPV6 Flow Label
> ###
> IPV6_
>
>                                               ICMP Packet Type. This is
>    ICMP_TYPE                    32      1     reported as (ICMP Type *
>                                               256) + ICMP code
>
>    IGMP_TYPE                    33      1     IGMP Packet Type
>
>                                               When using Sampling,
>                                               the rate at which
>                                               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

Guess it should be 2 or 4 bytes

>
>
> ###
> 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
>
> Sadasivan & Claise                                             [Page 25]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>                                               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.
>
>    OUT_BYTES_32                 38      4     32-bit counter for bytes
>                                               associated with an IP Flow
>
>    OUT_PKTS_32                  39      4     32-bit counter for packets
>                                               associated with an IP Flow
>
>    OUT_BYTES_64                 40      8     64-bit counter for bytes
>                                               associated with an IP Flow
>
>    OUT_PKTS_64                  41      8     64-bit counter for packets
>                                               associated with an IP Flow
>                                               inside TCP/UDP destination
>
>    INSIDE_L4_SRC                42      2     port number (.e.g, FTP,
>                                               Telnet, etc...)
>                                               only applicable with NAT
>
>    INSIDE_IPV4_SRC_ADDR         43      4     Source IPv4 Address
>                                               only applicable with NAT
>
>                                               TCP/UDP destination port
>    INSIDE_L4_DST_PORT           44      2     number (.e.g, FTP, telnet
>                                               etc...)
>                                               only applicable with NAT
>
>    INSIDE_IPV4_DST_ADDR         45      4     Destination IPv4 Address
>                                               only applicable with NAT
>
>    INSIDE_IPV6_SRC_ADDR         46      16    IPv6 Source Address
>                                               only applicable with NAT
>
>    INSIDE_IPV6_DST_ADDR         47      16    IPv6 Destination Address
>                                               only applicable with NAT
>
>                                               TCP/UDP destination port
>    OUTSIDE_L4_SRC_PORT          48       2    number (.e.g, FTP, Telnet,
>                                               etc...)
>                                               only applicable with NAT
>
>    OUTSIDE_IPV4_SRC_ADDR        49       4    Source IPv4 Address
>
> Sadasivan & Claise                                             [Page 26]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>                                               only applicable with NAT
>                                               TCP/UDP destination port
>    OUTSIDE_L4_DST_PORT          50       2    number (.e.g, FTP, Telnet,
>                                               etc...)
>                                               only applicable with NAT
>
>    OUTSIDE_IPV4_DST_ADDR        51       4    Destination IPv4 Address
>                                               only applicable with NAT
>
>    OUTSIDE_IPV6_SRC_ADDR        52       16   IPv6 Source Address
>                                               only applicable with NAT
>
>    OUTSIDE_IPV6_DST_ADDR        53       16   IPv6 Destination Address
>                                               only applicable with NAT
>
>    Flow Direction               54       1    The direction of the flow
>                                               observed at the
>                                               observation point. If the
>                                               observation point is a set
>                                               of interface(s) the
>                                               direction is w.r.t the
>                                               wire.
>
>    The "Value" column in the above table is a numeric identifier for the
>    field type.
>
>    When extensibility is needed (when new technologies are defined or
>    when some new field types are needed), the newly added field types
>    MUST be added to the list. They MUST be defined by the exporter and
>    understood by the collector.
>
> 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.

agreed.

>
>
>    The collector SHOULD maintain a table of active templates. The
>    template information SHOULD be kept for templates of flow records,
>    non-flow records, and dependency template. The table format is as
>    defined below.
>
> Sadasivan & Claise                                             [Page 27]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    +-----------+--------------+--------------+-----------------+
>    | Exporter  | Template ID  | Template Def |Time Since Last  |
>    |           |              |              |Refresh (Tr)     |
>    +-----------+--------------+--------------+-----------------+
>
>    Note that the Template IDs are unique per exporter. A template can
>    exist without being refreshed by an update for Tm period of time. Tr
>    gets incremented periodically. Each time an update is received for a
>    template, Tr is reset to 0. When Tr >= Tm, the entry is removed from
>    the table.
>
>    Collector devices SHOULD use the combination of the source IP address
>    and the Source ID field to distinguish different export streams
>    originating from the same exporting device. For example: different
>    linecards on a router MAY generate different export streams to a
>    single collector.
>
> Acknowledgements
>
>    We like to thank Will Eatherton, Michelle Ma, Peram Marimuthu, Martin
>    Djernaes and Vamsi Valluri for reviewing this document and providing
>    valuable comments.
>
> References
>
>    [1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt>
>    <http://www.ietf.org/html.charters/ipfix-charter.html>
>
>    [2] B. Carpenter, "Middleboxes: taxonomy and issues", draft-
>    carpenter-midtax-01.txt, work in progress.
>
>    [3] RFC 3022, Traditional IP Network Address Translator (Traditional
>    NAT)
>
> Authors' Addresses
>
>    Ganesh Sadasivan
>    Cisco Systems, Inc.
>    170 W. Tasman Dr.
>    San Jose, CA 95134
>    USA
>    Phone:  +1 (408) 527-0251
>    Email:  [email-masked]
>
> Sadasivan & Claise                                             [Page 28]
>
> Internet Draft    draft-gsadasiv-ipfix-proposal-00.txt     February 2002
>
>    Benoit Claise
>    Cisco Systems
>    De Kleetlaan 6a b1
>    1831 Diegem
>    Belgium
>    Phone: +32 2 704 5622
>    Email: [email-masked]
>
> Sadasivan & Claise                                             [Page 29]

---

From: [email-masked]
Date: Wed, 13 Feb 2002 08:21:24 -0500

>There is the problem you mentioned above in such a case.

	Keep in mind that the flow key will give 
	an indication of the affect of changes like this.

	FOr example, if the key is src-ip, dst-ip
	but the flow still reports src-AS and dst-AS
	the collector knows there is a possability
	the AS could change and no new flow would
	be reported.

	If on the other had the key was src-ip, dst-ip, src-AS, dst-AS
	then the collector knows that any change would create a new
	flow.

	I'm assuming here that we are not limited to 
	only reporting atttributes in the flow key.

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