[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

IPFIX working group                      EDITORS:     K.C. Norseth
Internet Draft                                  Enterasys Networks
draft-ietf-ipfix-data-00.txt                           Paul Calato
Expires: August 2002                       Riverstone Networks Inc



                         IPFIX Data Model
              Data Model for IP Flow Information Export
                   draft-ietf-ipfix-data-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups. Note that other groups may also distribute working
   documents as Internet-Drafts. Internet-Drafts are draft
   documents valid for a maximum of six months and may be updated,
   replaced, or obsoleted by other documents at any time. It is
   inappropriate to use Internet- Drafts as reference material or
   to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document defines an information and daqta model for
   scalable monitoring, measuring and exporting IP flow information
   to collectors.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in RFC-2119 [ ].


   1. Introduction                                                3
   2. Scope                                                       3
   3. Terminology                                                 3
   4. Flow Type and Flow Definition                               3
   4.1. Observation Point                                         5
   4.2. Unidirectional and Bidirectional Flows                    5
   5. Metering Process Function                                   6
   5.1. Flow Classification                                       6

IPFIX Working Group            Expires August 2002         [Page 1]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   5.2. Selection Criteria Of Packets                             6
   5.2.1. Function on properties that determines a flow type (Fi) 7
   5.2.2. Sampling packets on a flow type (Si)                    7
   5.3. Selection Criteria of flows for export                    7
   5.4. Flow Expiration                                           7
   6. Information Model                                           8
   6.1. Attributes related to IP Packet Header                    8
   6.2. Attributes Related to Measurement                         9
   6.3. Attributes Related to Flow Definition                     9
   6.4. Attributes related to Upper Layers                        9
   7. Information Elements                                        9
   7.1. IP Address                                                9
   7.1.1. Source Address                                          9
   7.1.2. Destination Address                                    10
   7.1.3. NEXT_HOP_IP                                            10
   7.2. Time Stamps                                              10
   7.2.1. Flow Creation Time                                     10
   7.2.2. Flow End Time                                          10
   7.2.3. Flow Start UTC Time                                    11
   7.2.4. Flow End UTC Time                                      11
   7.2.5. Flow Update Start Time                                 11
   7.2.6. Flow Update End Time                                   11
   7.2.7. Flow Update Delta Time                                 11
   7.3. Service Types                                            11
   7.3.1. Class of Service                                       11
   7.3.2. TCP Control Bits                                       12
   7.3.3. Protocol Identifier                                    12
   7.3.4. Source Exporter Address                                12
   7.4. Flow End State                                           13
   7.5. Statistical Elements                                     13
   7.5.1. Byte Count                                             13
   7.5.2. Packet Count                                           13
   7.5.3. Dropped Byte Count                                     14
   7.5.4. Dropped Packet Count                                   14
   7.5.5. IPM_DPKTS                                              14
   7.5.6. IPM_DOCTETS                                            14
   7.6. Port Information                                         14
   7.6.1. Source Port                                            14
   7.6.2. Destination Port                                       14
   7.7. Autonomous System (AS)                                   15
   7.7.1. Source AS                                              15
   7.7.2. Destination AS                                         15
   7.7.3. Next Hop AS                                            15
   7.8. IfIndexes and Interfaces                                 15
   7.8.1. Ingress Port                                           15
   7.8.2. Egress Port                                            15
   7.8.3. Egress ATM Subinterface                                16
   7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE                        16
   7.9. NetMasks                                                 16
   7.9.1. Source Address Netmask                                 16
   7.9.2. Destination Address Netmask                            16
   7.10. BGP & Vlan 's                                           16
   7.10.1. Destination BGP Community                             16
   7.10.2. Source BGP Community                                  17

IPFIX Working Group            Expires August 2002         [Page 2]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   7.10.3. BGP_NEXT_HOP                                          17
   7.10.4. Source VLAN ID                                        17
   7.10.5. Destination VLAN ID                                   17
   7.11. Virtual Information                                     17
   7.11.1. Source Virtual Address                                17
   7.11.2. Source Virtual Port                                   18
   7.11.3. Destination Virtual Address                           18
   7.11.4. Destination Virtual Port                              18
   7.12. Vendor Specific                                         19
   7.13. Misc. Information Elements                              19
   7.13.1. Flow Label                                            19
   7.13.2. Flow Direction                                        19
   7.13.3. Fragment ID                                           19
   7.13.4. Internal queue priority                               19
   7.13.5. Global VPN Identifier                                 20
   7.13.6. ICMP_TYPE                                             20
   7.13.7. IGMP_TYPE                                             20
   7.14. Sampling                                                20
   7.14.1. SAMPLING_INTERVAL                                     20
   7.14.2. SAMPLING_ALGO                                         20
   8. IANA Consideration                                         20
   9. Security Section                                           20
   10. References                                                21
   11. Acknowledgements                                          22
   12. Author's Addresses                                        23
   13. Full Copyright Statement                                  24
   14. To Add                                                    24

1. Introduction

   Many applications e.g., Intrusion detection, traffic
   engineering, require the monitoring, measuring of IP traffic
   flows. It is hence important to have a standard way of exporting
   information related to IP flows. This document defines the data,
   which may be used by the exporter for IP traffic flow monitoring
   an measuring.


2. Scope

   This document defines information data model for IPFIX[3].
   Specifically, this document describes a general purpose flow
   definition along with the data elements which may be exported.


3. Terminology

   To be filled out

4. Flow Type and Flow Definition

   As defined in the requirement draft [1],

      "A flow is a set of packets passing an observation point in

IPFIX Working Group            Expires August 2002         [Page 3]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

      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 (e.g. destination IP
        address)

      B. one or more properties of the packet itself (e.g. packet
        length)
      C. one or more of fields derived from packet treatment (e.g. AS
        number)

   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 these are different
   flows.

         1. {192.1.40.1, 171.6.23.5, 4}
         2. {192.1.40.23, 171.6.23.67, 4}
         3. {192.1.40.23, 171.6.23.67, 2}
         4. {198.20.9.200, 171.6.23.67, 4}

   Example 2:

   To create flows, we can apply a match function to all the packets
   that pass through an observation point, in order to aggregate some
   values. This could be done by defining the keys as {source IP
   address, destination IP address, TOS} like in the example 1, and
   applying the function which masks the least significant 8 bits of
   the source IP address and destination IP address (i.e. the
   resultant is a /24 address).  The 4 flows from example 1 would now
   be aggregated into 3 flows, by merging the flows 1. and 2. into a
   single flow.

         1. {192.1.40.0/24, 171.6.23.0/24, 4}
         2. {192.1.40.0/24, 171.6.23.0/24, 2}
         3. {198.20.9.0/24, 171.6.23.0/24, 4}

   Example 3:


IPFIX Working Group            Expires August 2002         [Page 4]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

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

   The above example can be thought of as a function F takes as input
   {source IP address, destination IP address, TOS}. The function
   selects only the packets which satisfy all the 3 conditions which
   are:

      * mask the least significant 8 bits of source IP address,
        compare against 192.1.40.0.
      * mask the least significant 8 bits of destination IP address,
        compare against 171.6.23.0.
      * tos value equal to 4.

   Depending on the values of {source IP address, destination IP
   address, TOS} of the different observed packets, the metering
   process function F would choose/filter/aggregate different sets of
   packets, which would create different flows.  In other words,
   based on various combination of values of {source IP address,
   destination IP address, TOS}, F(source IP address, destination IP
   address, TOS) would result in the definition of one or more flows.
   The function F is referred to as Flow Type.


4.1. Observation Point

   For definition refer to section 1.2. A flow is uniquely defined by
   the way it gets measured at an observation point.

   Example:

   The flow defined in the example 1 of section 2., can be used at 2
   different observation points 'a' and 'b' in 2 different ways.
   Observation point 'a' measures the packets that match the flow
   {192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and
   'b' measures packets that match the same flow with a sampling rate
   of 1 in 100.


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

IPFIX Working Group            Expires August 2002         [Page 5]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   bidirectional accounting information. This would save some
   bandwidth as the exporter won't have to send two unidirectional
   flow records.

   Let {KF1,KF2.., KFn} define the set of fields consisting of at
   least one of :

      a. one or more of packet header fields
      b. one or more properties of the packet itself
      c. one or more of fields derived from packet treatment

   The corresponding flow is F(KF1,KF2.., KFn). If the flow has any
   characteristics which  pertain to a direction w.r.t to the wire,
   then it is a uni-directional flow. Say <KFi, KFj> forms a pair
   which defines the <source, destination> characteristic in a
   direction w.r.t wire. If <KFj, KFi> defines the <source,
   destination> in the other direction w.r.t the wire, then Bi-
   directional flow can be defined as

        F(KF1,.. <KFj,KFi | KFi,KFJ> , ...KFn).

   Where "|" means "OR" and <> just delimits the internal set.


5.  Metering Process Functions

5.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 achieved are described in section 5.???


   In addition the collector, when it receives the flow records, MAY
   need the following interpreting the flow records further:

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


5.2. Selection Criteria Of Packets

   The measurement device MAY define rules so that only certain
   packets within a flow can be chosen for measurement at an

IPFIX Working Group            Expires August 2002         [Page 6]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   observation point. This MAY be done by one of the two types of
   methods defined below or a combination of them.  A combination of
   each of these ways can be adopted to select the packets .i.e. one
   can define a set of methods {F1, S1, F2, S2, S3} executed in
   certain sequence at an observation point to collect flows of a
   particular type.


5.2.1. Function on properties that determines a flow type (Fi)

   Packets that satisfy a function on the fields defined by the
   packet header fields or fields obtained while doing the packet
   processing or the properties of the packet itself.

   Example:

   Mask/Match of the fields that define a filter. The filter may be
   defined as {Protocol == TCP, Destination Port between 80 and 120}.


   Multiple such filters could be used in any sequence to select
   packets.


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


5.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 meet the following selection criteria are
   only exported.

      1 All flow records whose destination IP address matches
        {20.3.1.5}.
      2 Every other (.i.e. sampling rate 1 in 2) flow record whose
        destination IP address matches {160.0.1.30}.



IPFIX Working Group            Expires August 2002         [Page 7]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

5.4. Flow Expiration

   A flow is considered to be inactive if no packets of this flow has
   been observed at the observation point for a given timeout
   interval. The flow can be exported under the following conditions:

      1. If the exporter can deduce the end of a flow, the exporter
         SHOULD export the flow records when the end of the flow is
         detected. For example: flow generated by TCP type of traffic
         where the FIN or RST bits indicate the end of the flow

      2. If the flow has been inactive for a certain period of time.
         This inactivity timeout SHOULD be configurable.  For
         example: flow generated by UDP type of traffic.

      3. For long aging flows, the exporter SHOULD export the flow
         records on regular basis, in order to:

         a.  report the flow records periodic accounting information
             to the collector
         b.  avoid counter wrapping This activity timeout SHOULD be
             configurable

      4. If the exporter experiences resources constraints, a flow
         MAY be prematurely expired (example: memory)


6. Information Model

   The IPFIX information model is listed in the IPFIX requirement
   document.  The information model consists of the set of attributes
   that an IPFIX exporting device should be able to export. In
   conjunction with IP flow definitions, they provide locally
   accurate information about a flow.

   This section presents a rigorous definition and sufficient
   statistics for these attributes.


6.1. Attributes related to IP Packet Header

   The following attributes are obtained directly from IP packet
   header belonging to a flow:

      * IP Version Number
      * Source Address
      * Destination Address
      * Source Port (e.g. TCP port number)
      * Destination Port (e.g. TCP port number)
      * Protocol Type
      * TOS (for version 4)
      * Flow Label (for version 6)
      * DSCP (if DiffServ is supported)


IPFIX Working Group            Expires August 2002         [Page 8]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002


6.2. Attributes Related to Measurement

   The following attributes relates to measurements and measuring
   methodology:

      * Packet Counter
      * Dropped Packet Counter
      * Byte Counter
      * Dropped Byte Counter
      * Timestamp of the First Packet Observed
      * Timestamp of the Last Packet Observed
      * Timeout Indication
      * Sampling Method
      * Sampling Parameters


6.3. Attributes Related to Flow Definition

   The following attributes relates to IP flow definitions.

      * Incoming Interface
      * Outgoing Interface
      * Packet Treatment
      * Unique ID of the Observation Point
      * Unique ID of the Measuring Device


6.4. Attributes related to Upper Layers

   The following attributes provides information of lower layer
   protocols.

      * MPLS Label (if MPLS is supported)


7. Information Elements
   All element descriptions contain the following information:

   Field Type:
   This is the type of element the field is.  All values are defined
   in the TEXTUAL CONVENTIONS in the IETF rfcs.  For example, a
   source address is defined as field defined IpAddress from SNMPv2-
   SMI (RFC 1443).

   [This needs to be filled in on all the fields]

   Size:
   The size of the Data FlowSet including FlowSet ID and the Length .


7.1.IP Address

7.1.1. Source Address

IPFIX Working Group            Expires August 2002         [Page 9]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   Source address taken from the packet header. Addresses can be of
   any type as described in RFC 1700 [note - we need a new reference
   here, 1700 has been obsoleted]

        [ Do we want to be even more specific and say
          "taken from the IP packet header"
          Is there a reason to report L2 addresses?   ]

   Field Type: ###   Size: ###


7.1.2. Destination Address

   Destination address taken from the packet header. Address is
   defined the same as for Source Address.

   Field Type: ###   Size: ###


7.1.3. NEXT_HOP_IP

   Address of the next hop. address is defined the same as for Source
   Address .

   Field Type: ###   Size: ###


7.2.Time Stamps


        [ Note - there are several concepts in the time
                 section. We certainly can and will argue
                 about whether there is unnecessary
                 duplication or not.
          For now I just wanted to get the ideas down
        ]


7.2.1.   Flow Creation Time

   The time at which the flow was created. The time is a
   SNMPv2 TimeStamp [1443].


   Field Type: ###   Size: ###

7.2.2.   Flow End Time

   The time at which the flow was deleted. The time is a SNMPv2
   TimeStamp [1443].

        [ Do we need a reason code? e.g. inactivity,
          detected TCP FIN.
        ]

IPFIX Working Group            Expires August 2002         [Page 10]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002


   Field Type: ###   Size: ###


7.2.3. Flow Start UTC Time

   The time in seconds since 00:00:00 UTC, January 1, 1970 associated
   with the status/statistics observed or other events. If both Time
   and UTC_TIME are present, UTC Time takes precedence.

   Field Type: ###   Size: ###

7.2.4. Flow End UTC Time

   The time in seconds since 00:00:00 UTC, January 1, 1970 associated
   with the status/statistics observed or other events.

        [ Need to define what happens if more If both Time IE is
          present ]

   Field Type: ###   Size: ###


7.2.5. Flow Update Start Time

   Defines the time at the start of the flow Update. The time is a
   SNMPv2 TimeStamp [1443].

   Field Type: ###   Size: ###

7.2.6. Flow Update End Time

   Defines the time at the end of the flow Update. The time is a
   SNMPv2 TimeStamp [1443].

   Field Type: ###   Size: ###

7.2.7. Flow Update Delta Time

   The time covered by the update (e.g. update end -
   update_start).The time is in 100ths of seconds.

   Field Type: ###   Size: ###


7.3.Service Types

7.3.1. Class of Service

   The class of service associated with a flow.

   Class of Service Received
   Class of Service Transmitted


IPFIX Working Group            Expires August 2002         [Page 11]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

      1. IPv4, CoS value is defined by ToS in RFC 791
      2. IPv6, CoS value is defined by Traffic Class in RFC 2460
      3. MPLS, CoS value is defined by Exp in RFC 3032
      4. VLAN, CoS value is defined by user_priority in
         IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]

   [Can more than one Class of Service can be present???]


   Field Type: ###   Size: ###

7.3.2.TCP Control Bits

   The TCP control bits seen for this flow. Note a 0 value for each
   bit only indicates that the flag was not detected (i.e. it may
   have occurred but was not detected by the reporting CCE). TCP
   Control Bits are defined by RFC 793.

        [ Do we need another field with a more definitive
          meaning for 0??
        ]

   Field Type: ###   Size: ###

7.3.3.Protocol Identifier

   e.g. TCP/UDP [ need an RFC reference here. PAC]


   Field Type: ###   Size: ###

7.3.4. Source Exporter [ is that the right term?? PAC] Address

   Source Exporter address is the address of the Exporter reporting
   the flow, Address is same as is as shown for Source Address. This
   information is used by applications to later correlate the
   ingress/egress port with a specific Exporter. It is also used to
   maintain the source Exporter information when there is an
   intermediate proxy. For example, given the picture below:

               SW1 --------    P1 ------ Collector
                               ^
                               |
               SW2----------   |

   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector [ is this the right term??? PAC]  like the same Exporter
   connection. With the Source Exporter in the message the original
   Exporter  address is maintained.

        [ Does this belong here or in the Arch doc? I think
          in the arch doc.
        ]


IPFIX Working Group            Expires August 2002         [Page 12]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002


   Field Type: ###   Size: ###

7.4. Flow End State

   The reason the flow has ended.

        1. Inactivity timeout
        2. End of flow detected (e.g. TCP FIN)
        3. Forced end ????
        4. Cache full


   Field Type: ###   Size: ###


7.5.Statistical Elements

   To be expanded


7.5.1. Byte Count

   Contains the count of octets sent and received associated with the
   identified flow.

   The byte count can be for bytes received (towards source) or bytes
   sent (towards destination) or both (bi-directional flow).

   The byte count can be a running counter and is the count from the
   beginning of the flow establishment.

   The byte count can be a delta counter and is the count since the
   last report for this flow.

   Field Type: ###   Size: ###


7.5.2. Packet Count

   Contains the count of packets sent and received associated with
   the identified flow.

   The packet count can be for packets received (towards source) or
   packets sent (towards destination) or both (bi-directional flow).

   The packet count can be a running counter and is the count from
   the beginning of the flow establishment.

   The packet count can be a delta counter and is the count since the
   last report for this flow.

   Field Type: ###   Size: ###


IPFIX Working Group            Expires August 2002         [Page 13]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002


7.5.3. Dropped Byte Count

   Contains the count of octets dropped at the observation point
   associated with the identified flow.

   The dropped byte count can be a running counter and is the count
   from the beginning of the flow establishment.

   The byte count can be a delta counter and is the count since the
   last report for this flow.

   Field Type: ###   Size: ###


7.5.4. Dropped Packet Count

   Contains the count of packets dropped at the observation point
   associated with the identified flow.

   The dropped packet count can be a running counter and is the count
   from the beginning of the flow establishment.

   The dropped packet count can be a delta counter and is the count
   since the last report for this flow.

   Field Type: ###   Size: ###


7.5.5.   IPM_DPKTS
   Packet count for IP Multicast

   Field Type: ###   Size: ###

7.5.6.   IPM_DOCTETS

     Octet (byte) count for IP Multicast

   Field Type: ###   Size: ###

7.6.Port Information

   To be added


7.6.1. Source Port

   This information element is used to report  UDP source port [see
   RFC 768] or TCP source port [see RFC 793] as taken from the IP
   header.

   Field Type: ###   Size: ###



IPFIX Working Group            Expires August 2002         [Page 14]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

7.6.2. Destination Port

   This information element is used to report  UDP destination port
   [see RFC 768] or TCP destination port [see RFC 793] as taken from
   the IP header.

Field Type: ###   Size: ###


7.7.Autonomous System (AS)

   To be added

   Field Type: ###   Size: ###

7.7.1. Source AS

   The Autonomous System (AS) numbers for the source address
   associated with a flow. Autonomous System (AS) number is defined
   by RFC 1930 and RFC 1771 (BGP-4):

   Field Type: ###   Size: ###


7.7.2. Destination AS

   The Autonomous System (AS) numbers for the destination address
   associated wit a flow. Autonomous System (AS) number is defined by
   RFC 1930 and RFC 1771 (BGP-4).

   Field Type: ###   Size: ###


7.7.3.Next Hop AS

   The Autonomous System (AS) numbers for the next hop IP. Autonomous
   System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).

   Field Type: ###   Size: ###


7.8.IfIndexes and Interfaces

   To be added


7.8.1. Ingress Port

   The ifIndex where the packets for the flow are being received.
   ifIndex is defined by RFC 2233.


   Field Type: ###   Size: ###


IPFIX Working Group            Expires August 2002         [Page 15]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

7.8.2. Egress Port

   The ifIndex where the packets for the flow are exiting. ifIndex is
   defined by RFC 2233.

        [ Do multi-cast flow cause us to possible have
          more than one of these??

          PAC

        ]

   Field Type: ###   Size: ###


7.8.3. Egress ATM Subinterface

   The egress vpi/vci for the flow is provided in this Information
   element. vpi/vci id defined by the ATM Forum UNI 3.1
   specification:

   Field Type: ###   Size: ###


7.8.4. EGRESS_FRAME_RELAY_SUBINTERFACE

   The egress DLCI for the flow is provided in this Information
   element. ITU Q.922 defines the DLCI range. The frDlcmiState is
   defined in RFC 2115 and defines the specific values of the DLCI.

   Field Type: ###   Size: ###

7.9.NetMasks
7.9.1. Source Address Netmask

   The number of bits in the CIDR netmask, as defined in RFC 1519,
   for the source address.

   Field Type: ###   Size: ###


7.9.2. Destination Address Netmask

   The CIDR netmask, as defined in RFC 1519, for the destination
   address.

   Field Type: ###   Size: ###


7.10.BGP & Vlan 's

7.10.1. Destination BGP Community

   The BGP community number for the destination address. BGP

IPFIX Working Group            Expires August 2002         [Page 16]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   community number is defined by RFC 1997:

   Field Type: ###   Size: ###


7.10.2. Source BGP Community

   The BGP community number for the source address.

   Field Type: ###   Size: ###


7.10.3.   BGP_NEXT_HOP

   Next-hop router in the BGP domain

   Field Type: ###   Size: ###


7.10.4. Source VLAN ID

   The Source VLAN ID associated with the flow. VLAN ID is defined by
   IEEE standard 802.1q - 1998[802.1q].

      [ Is this ultimate source VLAN or the source vlan of the port
        where the packet came in? Or do we need a way to represent
        both? ]

   Field Type: ###   Size: ###


7.10.5. Destination VLAN ID

   The destination VLAN ID associated with the flow. VLAN ID is
   defined by IEEE standard 802.1q - 1998[802.1q].

[ Is this ultimate destination VLAN or the destination vlan of
     the port where the packet went out? Or do we need a way to
     represent both?]

   Field Type: ###   Size: ###

7.11.Virtual Information

7.11.1. Source Virtual Address

   An Exporter may be involved in redirecting flows. This information
   element captures information needed for proper accounting of
   redirected flows. The Source Virtual information element contains
   the source address of the flow as transmitted by the Exporter. It
   is generally different than the source address information
   element, which contains the address of the actual source of the
   message.


IPFIX Working Group            Expires August 2002         [Page 17]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   A type field would contain the type of translation performed on
   the source address. The following types are currently available:

         1 - NAT
         2 - LSNAT
         3 - Web Cache

   The address is defined the same as for Source Address.

   Field Type: ###   Size: ###


7.11.2. Source Virtual Port

   A CCE may be involved in redirecting flows. This information
   element captures information needed for proper accounting of
   redirected flows. The Source Virtual port information element
   contains the source port of the flow as transmitted by the CCE. It
   may be different than the source port information element, which
   contains the port of the actual source of the flow.  An IP
   Protocol field is present and is defined by the IP protocol spec
   [RFC 791] (e.g. TCP/UDP). The fields indicate how to interpret the
   port value field.

   A type field contains the type of translation performed on the
   source port. The following types are currently available:

      1 - NAT
      2 - LSNAT
      3 - Web Cache

   Field Type: ###   Size: ###


7.11.3. Destination Virtual Address

   The Destination Virtual information element contains the
   destination address of the flow as received by the Exporter. It is
   generally different than the destination port number, which
   contains the actual destination address of the flow.

   Field Type: ###   Size: ###


7.11.4. Destination Virtual Port

   The Destination Virtual port information element contains the
   destination port of the flow as received by the Exporter. It may
   be different than the destination port recorded in the destination
   port, which contains the actual destination port of the flow.

   Field Type: ###   Size: ###



IPFIX Working Group            Expires August 2002         [Page 18]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

7.12. Vendor Specific

   Vendors may add their own information to the protocol. Information
   contained in this information element is vendor specific. OID and
   OID Value are defined by ITU X.680.X683 (1997) and are encoded as
   defined by ITU X.690.691(1997). This information element MUST not
   contain any information which cannot be safely ignored by the
   Exporter or Collector. If multiple Vendor Specific information

   element's with the same OID occur, then the vendor defines
   semantics of ordering.

   Field Type: ###   Size: ###


7.13.Misc. Information Elements

7.13.1.Flow Label

   The Flow Label information element contains the IPV6 Flow Label
   information as defined by RFC 2460.

   Field Type: ###   Size: ###


7.13.2.   Flow Direction

   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.

   Field Type: ###   Size: ###


7.13.3. Fragment ID

   The fragment ID associated with the flow. RFC 791 and RFC 2460

   define fragment ID.

Field Type: ###   Size: ###


7.13.4. Internal queue priority

   A switch may map several of its internal priority queues into a
   Premium, High, Medium or Low category.

   [ This section needs more]

   Field Type: ###   Size: ###


7.13.5.Global VPN Identifier

IPFIX Working Group            Expires August 2002         [Page 19]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002


   The VPN identifier associated with the flow as defined in RFC
   2685.

   Field Type: ###   Size: ###


7.13.6.   ICMP_TYPE

   ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP
   code

   [We need a spec reference.]

   Field Type: ###   Size: ###


7.13.7.   IGMP_TYPE

   IGMP Packet Type

   [We need a spec reference.]

   Field Type: ###   Size: ###


7.14.Sampling


7.14.1.   SAMPLING_INTERVAL

   When using Sampling, the rate at which packets is sampled. For
   example, a value of 100 indicates that one of every hundred
   packets is sampled.

   Field Type: ###   Size: ###


7.14.2.   SAMPLING_ALGO

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

   Field Type: ###   Size: ###


8. IANA Consideration

   To be filled out.


9. Security Section
   To be filled out.

IPFIX Working Group            Expires August 2002         [Page 20]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002



10. References

   3.   J. Quittek ,et al.," Requirements for IP Flow Information
   Export ", (work in progress) ,Internet Draft, Internet
   Engineering Task Force, <draft-ietf-ipfix-reqs-00.txt>,
   November 2001

   4.   M. Wood ,et al.," Intrusion Detection Message Exchange
   Requirements",(work in progress), Internet Draft, Internet
   Engineering Task Force, draft-ietf-idwg-requirements-
   06,February 2002.

   5.   Daniel O. Awduche, et. al.," Overview and Principles of
   Internet Traffic Engineering", (work in progress), Internet
   Draft, Internet Engineering Task Force, draft-ietf-tewg-
   principles-02.txt, May 2002


   [Brow00] Nevil Brownlee: Packet Matching for NeTraMet
   Distributions,
   http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-
   adelaide/pp-dist/

   [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation
   Metric for IPPM,
   <draft-ietf-ippm-ipdv-08.txt>, November   2001

   [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet
   Loss Metric for IPPM, September 1999

   [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun:
   Application of Sampling  Methodologies to Network Traffic
   Characterization, Proceedings of ACM SIGCOMM'93,
   San Francisco, CA, USA,  September 13 - 17, 1993

   [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed
   MARTENS, John G. CLEARY:
   Nonintrusive and Accurate Measurement of Unidirectional Delay and
   Delay Variation on
   the Internet, INET'98, Geneva, Switzerland,  21-24 July, 1998

   [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory
   Sampling for Direct Traffic
   Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
   August 28 -
   September 1, 2000.

   [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay
   Metric for IPPM,
   Request for Comments: 2679, September 1999

   [ZsZC01]     Tanja Zseby, Sebastian Zander, Georg Carle:

IPFIX Working Group            Expires August 2002         [Page 21]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   Evaluation of Building Blocks
   for Passive One-way-delay Measurements, Proceedings of Passive and
   Active Measurement
   Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
   (PAM 2001)

   [MCFW] Srisuresh, S. et al.  "Middlebox Communication Architecture
   and framework," work in progress.  October 2001.

   [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
   Translator (NAT) Terminology and Considerations", RFC 2663, August
   1999.

   [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
   Address Translator (Traditional NAT)", RFC 3022, January  2001.

   [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for
   Provider Provisioned Virtual Private Networks ", work in progress,
   <draft-ietf-ppvpn-framework-03.txt>, January 2002.

   [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
   <draft-ietf-ppvpn-l2vpn-00.txt>, July 2001.

   [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z.
   and W. Weiss, "An Architecture for Differentiated Services", RFC
   2475, December 1998.

   [1] Requirements for IP Flow Export, <draft-ietf-ipfx-req-00.txt>
   <http://www.ietf.org/html.charters/ipfix-charter.html>

   [2] K.Zhang, et al., "Common Reliable Accounting for Network
   Element (CRANE)", <draft-kzhang-crane-protocol-02.txt>, February
   2002

   [3] G. Sadasivan, et al., "Flow Export Architecture", <draft-
   cisco-ipfix-arch-00.txt>, January 2002

   [4] Carlson, James, "PPP Design, Implementation and Debugging",
   Second Edition .



11. Acknowledgements
   We like to thank all the people contributing to the requirements
   discussion on the mailing list, and the design teams for a lot of
   valuable comments.

   George Carle
   Tanja Zseby
   Paul Calato
   Dave Plonka
   Kevin Zhang
   KC Norseth
   Benoit Claise

IPFIX Working Group            Expires August 2002         [Page 22]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   Ganesh Sadasivan
   Vamsi Valluri
   Ram Gopal
   Jc Martin
   Carter Bullard
   Juergen Quittek
   Reinaldo Penno
   Nevil Brownlee
   Simon Leinen


12. Author's Addresses

   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium
   Phone: +32 2 704 5622
   Email: bclaise@cisco.com

   Paul Calato
   Riverstone Networks, Inc.
   5200 Great America Parkway
   Santa Clara, CA 95054  USA
   Phone:  +1 (603) 557-6913
   Email:  calato@riverstonenet.com

   Ganesh Sadasivan
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   USA
   Phone:  +1 (408) 527-0251
   Email:  gsadasiv@cisco.com

   Ram Gopal
   Nokia
   5 Wayside Road,
   Burlington, MA 01803
   Phone:+1 781 993 3685
   Email: ram.gopal@nokia.com

   Man Li
   Nokia
   5 Wayside Road,
   Burlington, MA 01803
   Phone: +1 781 993 3923
   Email: man.m.li@nokia.com

   K.C. Norseth
   Enterasys Networks
   2691 S. Decker Lake Lane
   Salt Lake City, Utah 84119

IPFIX Working Group            Expires August 2002         [Page 23]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   Phone: +1 801 887 9823
   Email: knorseth@enterasys.com

   Reinaldo Penno
   Nortel Networks, Inc.
   2305 Mission College Boulevard
   Building SC9-B1240
   Santa Clara, CA 95134
   Email: rpenno@nortelnetworks.com

   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   69115 Heidelberg
   Germany
   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de

   Kevin Zhang
   XACCT Technologies, Inc.
   2900 Lakeside Drive
   Santa Clara, CA 95054
   Phone +1 301 992 4697
   Email: kevin.zhang@xacct.com

   Tanja Zseby
   GMD FOKUS
   Kaiserin-Augusta-Allee 31
   10589 Berlin, Germany
   Phone: +49 30 3463 7153
   Email: zseby@fokus.gmd.de



13. Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright
   notice and this paragraph are included on all such copies and
   derivative works. However, this document itself may not be
   modified in any way, such as by removing the copyright notice or
   references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into.

14. To Add

   We should have as example of how the flow packet works.  A good

IPFIX Working Group            Expires August 2002         [Page 24]


INTERNET-DRAFT   draft-ietf-ipfix-data-00.txt  Feb. 22, 2002

   example is what a NetFlow v5 packet looks like  with this data
   model.


















IPFIX Working Group            Expires August 2002         [Page 25]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/