Subject: Re: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update)

From: Jeff Meyer <[email-masked]>
Date: Sun, 01 Sep 2002 01:29:10 -0700

Hi,

   I'm not sure how to interpret the absence of documents
for the other protocols, but here is IPDR's advocacy
statement under the Sept. 2 deadline:

http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.txt

   Given the short notice of the reminder sent on Aug. 29,
I will continue to update this over the next two days, before
submitting to the IETF editor for drafts on Sept. 2.  So the
above link is likely to be updated after the initial delivery
of this e-mail.

   The initial (incomplete) IPDR IPFIX advocacy draft can
be found at
   http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.txt

or

http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.html

The XML source for this document is available at:

http://www.ipdr.org/documents/ipfix/draft-advocate-ipfix-IPDR-eval-00.xml

The base source of this document is XML, written according to RFC2629,
described in:

http://xml.resource.org/public/rfc/html/rfc2629.html

I would recommend this code to other protocol advocates who
are interested in utilizing the XML formatting web services
available at:

http://xml.resource.org/

This allows you to produce .html, .txt, and .nroff files from the
same XML source file.

Regards,

   Jeff Meyer
   www.hp.com/usage

Juergen Quittek wrote:

> Hi Ram,
> 
> -- [email-masked] wrote on 30 August 2002 08:18 -0400:
> 
>> Hello Juergen,
>>
>> Sorry, the earlier  email slips out of my hands.  I interpreted as Sep 
>> 2  deadline for submission to evaluation team.
> 
> 
> Yes. Now I see what you mean. I just wanted to remind the declared
> (and all other potential) advocates of the deadline for the
> advocacy drafts that contain individual protocol evaluations.
> 
> Of course the deadline of the joint evaluation draft is later.
> 
>> Then at the earliest we should produce the evaluation document to the 
>> mailing list for  enough debate/discussion and it need not be on Sep 
>> 2nd itself.
> 
> 
> You are right. The joint draft is scheduled for Oct. 16.
> 
>>
>> FYI, I have completed reading all the IPFIX candidates and in  half 
>> way mark in documenting as per template. On the other side, I am also 
>> waiting  till Sep 2nd to see any other  IPFIX candidate protocol  
>> submission.
>>
> 
> Great!
> 
>    Juergen
> 
>>
>> Regards
>> Ramg
>>
>>> Hi Ram,
>>>
>>> You may be right, but how do you interpret the phrase
>>> "Advocacy drafts published" in this sniplet from Nevil's
>>> message?
>>>
>>> > >     2 September  Cutoff for Protocol Submissions to
>>> Evaluation Team
>>> > >                  Advocacy drafts published
>>>
>>>     Juergen
>>>
>>>
>>> -- [email-masked] wrote on 29 August 2002 14:13 -0400:
>>>
>>> > Hello Juergen,
>>> >
>>> > The 2 September is cut-off date for "protocol submission" and not
>>> > "protocol evaluation" document.
>>> >
>>> >
>>> > Regards
>>> > Ramg
>>> >
>>> >> -----Original Message-----
>>> >> From: ext Juergen Quittek [mailto:[email-masked]]
>>> >> Sent: Thursday, August 29, 2002 12:50 PM
>>> >> To: Nevil Brownlee; [email-masked]
>>> >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update)
>>> >>
>>> >>
>>> >> Dear protocol advocates:
>>> >>
>>> >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200:
>>> >>
>>> >> > Hello all:
>>> >> >
>>> >> > At the IPFIX meeting in Yokohama we reached consensus on
>>> >> the evaluation
>>> >> > process, with the following timetable:
>>> >> >
>>> >> >     5 July       Publish Protocol Advocacy draft and Call
>>> >> for Submissions
>>> >> >
>>> >> >    15 July       Work on consensus in Yokohama, agree on
>>> timetable
>>> >> >
>>> >> >     2 September  Cutoff for Protocol Submissions to
>>> Evaluation Team
>>> >> >                  Advocacy drafts published
>>> >>
>>> >> Please do not miss the cutoff date for the protocol
>>> >> evaluation drafts on next Monday.
>>> >>
>>> >>     Juergen
>>> >> --
>>> >> Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
>>> >> NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>>> >> Adenauerplatz 6, 69115 Heidelberg, Germany
>>> http://www.ccrle.nec.de
>>> >>
>>> >> --
>>> >> 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/
>>> >>
>>>
>>>
>>>
>>> -- 
>>> 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/
>>>
> 
> 
> 
> -- 
> 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/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Mon, 02 Sep 2002 17:16:37 +0200

Hi,

Please find attached draft-claise-ipfix-eval-netflow-00.txt.
Note that I will continue to update this draft over the next days and 
produce the version 01.
A few sections from the verison 00 contains the sentence "to be written".

Regards, Benoit.

   Internet Draft                                             B. Claise 
   Document: draft-claise-ipfix-eval-netflow-00.txt       Cisco Systems 
   Expires: Mars 2003                                    September 2002 

        Evaluation Of NetFlow Version 9 Against IPFIX Requirements 
                                      
                   <draft-claise-ipfix-eval-netflow-00.txt> 

Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of [RFC 2026]. 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 obsolete 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 
 
   Distribution of this document is unlimited. 
 
Copyright Notice 
 
   Copyright (C) The Internet Society (2001). All Rights Reserved. 

Abstract 
    
   This document provides an evaluation of the applicability of the NetFlow 
   flow record export protocol version 9 as an IPFIX protocol. It compares 
   the properties and capabilities of the NetFlow flow record export protocol 
   version 9 to the IPFIX requirements [IPFIX-REQ]. 
   This document is the first version of the draft and should not be 
   considered as finished work. Updated version(s) will soon follow with 

Claise                 Expires – February 2003               [Page 1] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   changes introduced by the publication of the new requirement draft version 
   6 [IPFIX-REQ6], and with the English syntax and grammar corrections.  

        Table of Contents 
    
   1. Introduction...................................................3 
   2. Architectural Considerations...................................5 
      2.1 NetFlow Protocol Overview..................................6 
      2.2 General Applicability......................................6 
        2.2.1 Flow Definition......................................6 
        2.2.2 Observation Point....................................7 
        2.2.3 The Metering Process and the Flow Record.............7 
        2.2.4 The Exporting Process................................7 
        2.2.5 The Collecting Process...............................7 
      2.3 Architectural Differences..................................8 
   3. Item Level Compliance Evaluation...............................9 
      3.1 Terminology (section 2)....................................9 
        3.1.1 IP Traffic Flow (2.1)................................9 
        3.1.2 Observation Point (2.2)..............................9 
        3.1.3 Metering Process (2.3)..............................10 
        3.1.4 Flow Record (2.4)...................................10 
        3.1.5 Exporting Process (2.5).............................10 
        3.1.6 Collecting Process (2.6)............................10 
      3.2 Applications Requiring IP Flow Information Export (3).....10 
      3.3 Distinguishing Flows (4)..................................11 
        3.3.1 Interface (4.1).....................................11 
        3.3.2 IP Header Fields (4.2)..............................11 
        3.3.3 Transport Header Fields (4.3).......................11 
        3.3.4 MPLS (4.4)..........................................11 
        3.3.5 DiffServ Code Point (4.5)...........................11 
        3.3.6 Header Compression and Encryption (4.6).............11 
      3.4 Metering Process (5)......................................11 
        3.4.1 Reliability (5.1)...................................12 
        3.4.2 Sampling (5.2)......................................12 
        3.4.3 Overload Behavior (5.3).............................12 
        3.4.4 Timestamps (5.4)....................................13 
        3.4.5 Time Synchronization (5.5)..........................13 
        3.4.6 Flow Expiration (5.6)...............................13 
        3.4.7 Multicast (5.7).....................................14 
        3.4.8 Ignore Port Copy (5.8)..............................14 
      3.5 Data Export (6)...........................................14 
        3.5.1 Information Model (6.1).............................14 
        3.5.2 Data Model (6.2)....................................15 
        3.5.3 Data Transfer (6.3).................................15 
          3.5.3.1 Congestion Awareness (6.3.1)....................15 
          3.5.3.2 Reliability (6.3.2).............................15 

Claise                   Expires – Mars 2003                  [Page 2] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

          3.5.3.3 Security (6.3.3)................................15 
        3.5.4 Regular Reporting Interval (6.4)....................16 
        3.5.5 Notification on Specific Events (6.5)...............16 
        3.5.6 Anonymization (6.6).................................16 
      3.6 Configuration (7).........................................16 
        3.6.1 Configuration of the Metering Process (7.1).........16 
        3.6.2 Configuration of the Exporting Process (7.2)........16 
      3.7 General Requirements Compliance (8).......................16 
        3.7.1 Openness (8.1)......................................16 
        3.7.2 Scalability Concerning the Number of Exporting Processes 
        (8.2) 16 
        3.7.3 Several Collecting Processes (8.3)..................17 
   4. Security Considerations.......................................17 
   5. References....................................................17 
   6. Author's Address..............................................18 
   7. Full Copyright Statement......................................18 

1. Introduction 
   
   This document provides an evaluation of the applicability of the NetFlow 
   flow record export protocol version 9 as an IPFIX protocol. First, the 
   general NetFlow architecture is introduced and its application to the 
   communication between an IPFIX exporting process and an IPFIX collecting 
   process is discussed in Section 2. Section 3 discusses in detail, to which 
   degree requirements stated in [IPFIX-REQ] are met. 
    
   This document uses the terminology defined in [IPFIX-REQ]. 
    
   Note that the generic term NetFlow refers to multiple different notions: 
   the metering process, the exporting process and the export protocol, as 
   defined in the IPFIX terminology section of [IPFIX-REQ]. 
   Even if the metering process and exporting process form a single NetFlow 
   process on the Cisco Systems devices, this document will sometimes refer 
   to NetFlow metering process and NetFlow exporting process for the sake of 
   clarity. But the export protocol will always be referred to as the NetFlow 
   flow record export protocol version 9.   
 
   -  How and where is it documented? 
             
   All documentation related to NetFlow can be found at: 
   http://www.cisco.com/go/netflow 
    
   More specifically, the “NetFlow Services Solutions Guide” covers a NetFlow 
   overview, the basic and advanced concepts, the explanation of the 

Claise                   Expires – Mars 2003                  [Page 3] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   different versions along with the data types exported, some configuration 
   examples, etc. For reference, see: 
   http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite
   .htm 
    
   The new flexible and extensible NetFlow flow record export version 9 is 
   described in the IETF draft "Cisco Systems NetFlow Services Export Version 
   9" [NETFLOW9], as well as in the following document: 
   http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ntfo_wp.htm 
    
   -  Are there concrete plans for standardizing it? 
    
   The way to standardize NetFlow is via the IETF IPFIX Working Group. 
   In parallel, Cisco Systems intention is to produce an Information RFC out 
   of [NETFLOW9].  
    
   -  Is standardization already in progress? 
    
   No other standardization than the participation to the IETF IPFIX Working 
   Group is currently taking place. 
    
   -  Is it proprietary to a certain company? 
    
   NetFlow is a proprietary protocol from Cisco Systems. 
    
   -  Does it include any technology protected by patents? 
    
   NetFlow is protected by the following patent: 
   United States Patent 6,243,667 Kerr, et al. June 5, 2001 
    
   Abstract: 
   The invention provides a method and system for switching in networks 
   responsive to message flow patterns. A message "flow" is defined to 
   comprise a set of packets to be transmitted between a particular source 
   and a particular destination. When routers in a network identify a new 
   message flow, they determine the proper processing for packets in that 
   message flow and cache that information for that message flow. Thereafter, 
   when routers in a network identify a packet which is part of that message 
   flow, they process that packet according to the proper processing for 
   packets in that message flow. The proper processing may include a 
   determination of a destination port for routing those packets and a 
   determination of whether access control permits routing those packets to 
   their indicated destination. 

Claise                   Expires – Mars 2003                  [Page 4] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   Nevertheless, Cisco Systems has no intention to use this patent to prevent 
   other vendors to implement a NetFlow-like solution. 
    
   An Intellectual Property Right message has been sent to the IETF rfc-
   editor team to post a similar message at http://www.ietf.org/ipr.html 
    
   -  Is it already implemented? 
 
   The NetFlow flow record export protocol version 9 protocol is currently at 
   the stage of the Early Field Test, while NetFlow flow record export 
   versions 1, 5, 7 and 8 have been implemented for years now. 
    
   -  Is it already in commercial use? 
    
   Some Cisco Systems partners are currently developing NetFlow Collectors 
   (the correct term is “collecting process” according to [IPFIX-REQ]) able 
   to receive NetFlow version 9 flow records. 
   While many different companies or organizations have already implemented 
   NetFlow Collectors for the previous NetFlow flow record export protocols 
   versions. Ex: Concord Communications, Hewlett Packard, Narus, Xacct, 
   Portal, Apogee Networks, Infovista, etc. to name just a few. 
    
   -  Is it available from more than one source? 
    
   As the inventor of NetFlow, Cisco Systems is the only company implementing 
   this new version 9 on its devices. But, if we speak of the previous 
   NetFlow flow record export protocol versions, then the majority of our 
   competitors implemented those versions.  
    
   -  Is it already widely used? 
    
   The new NetFlow flow record export protocol version 9 is in Early Field 
   Test right now, while the previous NetFlow flow record export versions 
   have been implemented by our competitors. As a consequence, NetFlow is 
   widely used through out the industry. 

2. Architectural Considerations 
    
   This section introduces the architecture of the NetFlow and suggests a way 
   of applying it to the communication between an IPFIX exporting process and 
   an IPFIX collecting process. 

Claise                   Expires – Mars 2003                  [Page 5] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

    
2.1 NetFlow Protocol Overview 
    
   This section discusses the most recent evolution of the NetFlow flow 
   record export protocol, which is known as Version 9. The distinguishing 
   feature of the NetFlow Version 9 format compared to the previous versions, 
   is that it is template based. Template is a collection of fields along 
   with the description of their structure and semantics.  
    
   This approach gives the following advantages: 
    
   - The template mechanism being flexible, allows the export of the   
   required fields alone from the IP Flows to the collecting process.     
   This helps to reduce the exported flow data volume, and possible     
   memory savings at the metering process and collecting process. 
   Sending the required information only, reduces the network load too.    
    
   - Using the template mechanism, new fields can be added to NetFlow   
   export records without changing the structure of export record  
   format. With the previous NetFlow flow record export versions,  
   adding a new field in the flow record implied a new version of the  
   export protocol format and a new version of the collecting process  
   that supports the parsing of this new export protocol format.  
    
   - Templates which are sent to the collecting process contains the  
   structural information about the exported Flow Records fields. So,  
   even if the collecting process does not understand the semantics of  
   new fields, it can still interpret the Flow Record.  
    
   - Even if the NetFlow flow record export protocol version 9 has been 
   created with a IP flow record background in mind, note that 
   Information Model can be extended with any data types and could 
   potentially serve any reporting purposes. E.g. the NetFlow metering 
   process configuration. 

2.2 General Applicability 

2.2.1 Flow Definition 

   A NetFlow flow is identified as a unidirectional stream of packets between 
   a given source and destination—both defined by a network-layer IP address 

Claise                   Expires – Mars 2003                  [Page 6] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   and transport-layer source and destination port numbers. Typically in case 
   of ingress NetFlow, a flow is identified as the combination of the 
   following seven key fields: source IP address, destination IP address, 
   source port number, destination port number, layer 3 protocol type, ToS 
   byte, input logical interface (ifIndex). In case of egress NetFlow, a flow 
   is identified as the combination of the following seven key fields: source 
   IP address, destination IP address, source port number, destination port 
   number, layer 3 protocol type, ToS byte, output logical interface 
   (ifIndex). 

   These seven key fields define a unique flow. If a new observed packet 
   contains a different set of these seven key fields, then this packet will 
   create a new flow. Note that a flow contains other accounting fields (such 
   as the number of packets, number of bytes, the BGP AS, etc). 

2.2.2 Observation Point 
   NetFlow is enabled in most case per interface (per port), sometimes per 
   subinterface. On specific device, NetFlow is enabled for the entire 
   platform. 

2.2.3 The Metering Process and the Flow Record 
   NetFlow operates by creating a NetFlow cache that contains the information 
   for all active flows. A flow record is maintained within the NetFlow cache 
   for all active flows. Each flow record in the NetFlow cache contains key 
   fields that can be later used for exporting to a collecting process. 

2.2.4 The Exporting Process 
   The NetFlow enabled platform checks the NetFlow cache once per second and 
   expires the flow if no more traffic of that flow is observed. Once 
   expired, the flow records are directly exported to the collecting process. 
   To achieve efficiency in terms of processing at the Exporter while 
   handling high volume of export, the NetFlow export packet is encapsulated 
   into UDP [UDP] datagrams for export to the collecting process. 
   Nevertheless NetFlow flow record export protocol version 9 has been 
   designed to be transport protocol independent. Hence, it can also operate 
   over congestion aware protocols like TCP [TCP] or SCTP [SCTP].  

2.2.5 The Collecting Process 

Claise                   Expires – Mars 2003                  [Page 7] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   NetFlow Collector (the collecting process) provides the data 
   collection from multiple export devices exporting NetFlow flow 
   records. It will process and store the flow records. Some extra 
   actions on these flow records could be executed on the collecting 
   process but per [IPFIX-REQ], these actions are out of the scope of 
   the IPFIX work. 

2.3 Architectural Differences 
    
                                 +----------------+   +----------------+ 
                                 |[*Application 1]| ..|[*Application n]| 
                                 +--------+-------+   +-------+--------+ 
                                          ^                   ^ 
                                          ~                   ~ 
                                          +~~~~~~~~~~+~~~~~~~~+ 
                                                     ! 
                                                     v 
      +----------------------+                +------------------+ 
      |Device(i)             |                | Collector(j)     | 
      |[Obsv Point(s)]       |--------------->| [*Application(s)]| 
      |[Metering Process(es)]|          +---->|                  | 
      |[Export Process]      |          |     +------------------+ 
      +----------------------+          . 
             ....                       .           
      +----------------------+          | 
      |Device(m)             |          |  
      |[Obsv Point(s)]       |----------+ 
      |[Metering Process(es)]|                 
      |[Export Process]      | 
      +----------------------+ 
    
   Except the terminology difference again described below, there is no 
   difference between the NetFlow and IPFIX architecture. 
   Note that the generic term NetFlow refers to multiple different notions: 
   the metering process, the exporting process and the export protocol, as 
   defined in the IPFIX terminology section of [IPFIX-REQ]. 
   Even if the metering process and exporting process form a single NetFlow 
   process on the Cisco Systems devices, this document will sometimes refer 
   to NetFlow metering process and NetFlow exporting process for the sake of 
   clarity. But the export protocol will always be referred to as the NetFlow 
   flow record export protocol version 9.  

 
Claise                   Expires – Mars 2003                  [Page 8] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

3. Item Level Compliance Evaluation 
    
   This section evaluates the compliance of the NetFlow protocol with the 
   IPFIX requirements item by item. Requirements are addressed by their 
   section numbers and item numbers in [IPFIX-REQ]. For each requirement 
   it is explained to what degree protocol NetFlow flow export version 9 
   meets the requirement and how this is achieved. The degree of compliancy 
   is explicitly stated using five grades: 
    
     -T  Total compliance: The requirement is met completely by the 
         protocol specification without any extensions required. 
    
     -E  Extension required for total compliance: The protocol is 
         prepared to be extended and it is possible to extend it in a 
         way that it meets the requirement. This grade is only 
         applicable to protocols that are explicitly open to externally 
         defined extensions, such as SNMP is extended by MIB modules or 
         DIAMETER is extended by application modules. It is not 
         applicable to protocols, where the protocol specification itself 
         needs to be extended in order to comply with the requirement. 
    
     -P  Partial compliance: The requirement is met partially by the 
         protocol specification. 
    
     -U  Upcoming compliance: The requirement is not met or met 
          partially by the protocol specification, but there is a 
          concrete plan for an upcoming version of the protocol. 
    
     -F  Failed compliance: The requirement is not met by the protocol 
     specification. 

3.1 Terminology (section 2) 

3.1.1 IP Traffic Flow (2.1) 
 
   Total compliance of NetFlow Flow definition with the IPFIX IP 
   Traffic Flow definition. 

3.1.2 Observation Point (2.2) 

 
Claise                   Expires – Mars 2003                  [Page 9] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   Total compliance of NetFlow Observation Point definition with the 
   IPFIX Observation Point definition. NetFlow is enabled by interface 
   or per subinterface.  NetFlow can be enable on multiple interfaces 
   at the same time, e.g. all interfaces belonging to one line card, or 
   all the interfaces from the device. On specific device, NetFlow is 
   enabled for the entire platform. 

3.1.3 Metering Process (2.3) 
 
   Total compliance of NetFlow with the IPFIX Metering Process 
   definition, for all aspects: packet header capturing, timestamping, 
   sampling, classifying, and maintaining flow records. 

3.1.4 Flow Record (2.4) 
 
   Total compliance of NetFlow Flow Record definition with the IPFIX 
   Flow Record definition. 

3.1.5 Exporting Process (2.5) 
 
   Total compliance of NetFlow Exporting Process with the IPFIX 
   Exporting Process definition. The NetFlow Exporting Process may send 
   the flow records to 2 different collecting processes. 

3.1.6 Collecting Process (2.6) 
 
   Total compliance of NetFlow Collector with the IPFIX collecting 
   process definition.  

3.2 Applications Requiring IP Flow Information Export (3) 
    
   Total compliance of NetFlow regarding the different applications 
   described in [IPFIX-REQ] which require IP flow information export, 
   i.e. Usage-based Accounting, Traffic Profiling, Traffic Engineering, 
   Attack/Intrusion Detection and QoS Monitoring. Actually, the 
   Information Model associated with NetFlow flow record export version 
   9 [NETFLOW9] contains all the data types needed to satisfy the 
   requirements of the different applications described in this 
   section. 

 
Claise                   Expires – Mars 2003                 [Page 10] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

3.3 Distinguishing Flows (4) 

3.3.1 Interface (4.1) 
    
   Total Compliance of the interface as a flow distinguisher. 
   In case of ingress NetFlow, a flow is identified, amongst other 
   fields, by the input logical interface (ifIndex). In case of egress 
   NetFlow, a flow is identified, amongst other fields by output 
   logical interface (ifIndex). 

3.3.2  IP Header Fields (4.2) 
 
    source IP address (MUST): Total Compliance 
    destination IP address (MUST): Total Compliance 
    protocol type (TCP,UDP,ICMP,...) (MUST): Total Compliance 
    IP version number (SHOULD): Upcoming Compliance 

3.3.3  Transport Header Fields (4.3) 
    
   Total Compliance of the port numbers of the transport header as a 
   flow distinguisher. 

3.3.4  MPLS (4.4) 
    
   Total Compliance of the MPLS label a flow distinguisher, if the 
   observation point is located at a device supporting Multiprotocol 
   Label Switching. 

3.3.5  DiffServ Code Point (4.5) 
    
   Partial Compliance, as NetFlow distinguish flow by the TOS field. 

3.3.6  Header Compression and Encryption (4.6) 
    
   Total Compliance. 

3.4 Metering Process (5)  

 
Claise                   Expires – Mars 2003                 [Page 11] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

3.4.1 Reliability (5.1) 
    
   To be written. 

3.4.2  Sampling (5.2) 
    
   “The metering process MAY support packet sampling.”, as defined in 
   [IPFIX-REQ]“. Total Compliance. NetFlow supports packet sampling. 
    
   “If sampling is supported the sampling configuration MUST be well 
   defined. The sampling configuration includes the sampling method and 
   all its parameters.”, as defined in [IPFIX-REQ]. Total compliance.  
   See the Options Template from [NETFLOW9]: a template that describes 
   the format of the Flow measurement parameters (like the sampling 
   algorithm, sampling interval) done at the metering process. 
    
   “If the sampling configuration is changed during operation, the new 
   sampling configuration with its parameters MUST be indicated to all 
   collecting processes receiving the affected flow records. Changing 
   the sampling configuration includes: start sampling, stop sampling, 
   change sampling method, and change sampling parameter.“, as defined 
   in [IPFIX-REQ]“. Partial Compliance. NetFlow supports the “change 
   sampling method” and “change sampling parameter” options. 

3.4.3  Overload Behavior (5.3) 
    
   “In case of an overload, for example lack of memory or processing 
   power, the metering process MAY change its behavior in order to cope 
   with the lack of resources.”, as defined in [IPFIX-REQ].  
   Total Compliance.  
    
   “But in case the overload behavior has an impact on the metering 
   process or the exporting process, the overload behavior MUST be 
   clearly defined and the collecting process MUST be able to 
   distinguish the flow records exported before and after the metering 
   process behavior change:”, as defined in [IPFIX-REQ]. 
   If the metering process configuration is changed, then Total 
   Compliance.  
   But failed compliance in the following situation: in case the 
   NetFlow cache becomes full, the flow records will be expired with a 
   smaller timeout! In this specific case, this requirement doesn’t 
   make sense. 
    
   “In case of any change of the meter's behavior, all flow records 
   metered by the previous behavior MUST be terminated and exported 

Claise                   Expires – Mars 2003                 [Page 12] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   according to the configuration of the exporting process.”, as 
   defined in [IPFIX-REQ]. 
   Total Compliance. 
    
   “The metering process MUST not merge the flow records generated with 
   the new behavior with the flow records generated with the previous 
   behavior.”, as defined in [IPFIX-REQ]. 
   If the metering process configuration is changed, then Total 
   Compliance because a new Template ID for the new configuration will 
   be generated. 
   But failed compliance in the following situation: in case the 
   NetFlow cache becomes full, the flow records will be expired with a 
   smaller timeout! In this specific case, this requirement doesn’t 
   make sense. 

3.4.4  Timestamps (5.4) 
    
   Total Compliance. 

3.4.5  Time Synchronization (5.5) 
    
   The compliance is not relevant as the mechanism used for time 
   synchronization is outside the scope of the IPFIX.  

3.4.6  Flow Expiration (5.6) 
    
   Total Compliance of the NetFlow flow expiration mechanism with the 
   IPFIX requirements. 
   The routing device checks the NetFlow cache once per second and expires 
   the flow in the following instances: 

       1. Transport is completed (TCP FIN or RST).  

       2. The flow cache has become full.  

       3. The inactive timer has expired after 15 seconds of traffic 
          inactivity. This inactive timer is configurable.  

       4. The active timer has expired after 30 minutes of traffic activity. 
          This active timer is configurable. 

 
Claise                   Expires – Mars 2003                 [Page 13] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

3.4.7 Multicast (5.7) 
    
   Total Compliance of the multicast support with the IPFIX 
   requirements. 

3.4.8 Ignore Port Copy (5.8) 
    
   To be written. 

3.5 Data Export (6)  

3.5.1 Information Model (6.1) 
 
   “The exporting process MUST be able to report the following 
   attributes for each metered flow”, as defined in [IPFIX-REQ]: 
    1. IP version number: Upcoming Compliance (NetFlow will support 
   IPV6) 
    2. source IP address: Total Compliance 
    3. destination IP address: Total Compliance 
    4. IP protocol type (TCP,UDP,ICMP,...) : Total Compliance 
    5. source TCP/UDP port number: Total Compliance 
    6. destination TCP/UDP port number: Total Compliance 
    7. input interface (ifIndex): Total Compliance 
    8. output interface (ifIndex): Total Compliance 
    9. packet counter: Total Compliance 
    10. byte counter: Total Compliance 
    11. in case of IPv4, Type of Service: Total Compliance 
    12. in case of IPv6, Flow Label: Upcoming Compliance 
    13. if BGP is supported at the observation point, BGP AS number: 
   Total Compliance 
    14. if MPLS is supported at the observation point, MPLS label: 
   Total Compliance 
    15. if DiffServ is supported at the observation point, DSCP: 
   Partial Compliance 
    16. timestamp of the first packet of the flow: Total Compliance 
    17. timestamp of the last packet of the flow: Total Compliance 
    18. if sampling is used, sampling configuration: Total Compliance 
    19. unique identifier of the observation point: Total Compliance 
   (the ifIndex) 
    20. unique identifier of the exporting process: Total Compliance 
   (the IP address) 
 
   “The exporting process SHOULD be able to report the following 
   attributes for each metered flow”, as defined in [IPFIX-REQ]: 

Claise                   Expires – Mars 2003                 [Page 14] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

     21. multicast replication factor. Total Compliance 
 
   “The exporting process MAY be able to report the following 
   attributes for each metered flow”, as defined in [IPFIX-REQ]: 
     22. Time To Live: Extension required for total compliance 
     23. IP header flags: Extension required for total compliance 
     24. TCP header flags: Total Compliance 
     25. dropped packet counter at the observation point: Extension 
     required for total compliance 
     26. fragmented packet counter: Extension required for total 
     compliance 

3.5.2 Data Model (6.2) 
     
   “The data model MUST be extensible”, as defined in [IPFIX-REQ]. 
   Total compliance. 
    
   “The data model used for exporting flow information MUST be flexible 
   concerning the flow attributes contained in flow records”, as 
   defined in [IPFIX-REQ]. 
   Total compliance. 
 
   “The Data Model SHOULD be independent of the underlying transport 
   protocol, i.e. the data transfer”, as defined in [IPFIX-REQ]. 
   Total compliance. 

3.5.3 Data Transfer (6.3) 

3.5.3.1   Congestion Awareness (6.3.1) 
    
   “For the data transfer, a congestion aware protocol MUST be 
   supported”, as defined in [IPFIX-REQ]. 
   To be written. 

3.5.3.2   Reliability (6.3.2) 
 
   Total Compliance. A sequence ID exists per export packet so that the 
   collecting process would know if it misses export packets or if 
   packets reordering occurred in the network. 

3.5.3.3   Security (6.3.3) 
    
   Failed compliance for confidentiality, integrity and authenticity. 

Claise                   Expires – Mars 2003                 [Page 15] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

3.5.4 Regular Reporting Interval (6.4) 
    
   Total compliance. For long aging flows, the exporting process 
   exports the flow records on regular basis, in order to: 
           1. report the flow records periodic accounting information 
               to the collecting process 
           2. avoid counter wrapping 
   This activity timeout is configurable 

3.5.5 Notification on Specific Events (6.5) 
    
   Failed compliance.  

3.5.6 Anonymization (6.6) 
    
   To be written. 

3.6 Configuration (7) 

3.6.1 Configuration of the Metering Process (7.1) 
    
   Total Compliance. 

3.6.2 Configuration of the Exporting Process (7.2) 
    
   Total Compliance. 

3.7 General Requirements Compliance (8) 

3.7.1  Openness (8.1) 
    
   Total Compliance. 

3.7.2 Scalability Concerning the Number of Exporting Processes (8.2) 

 
Claise                   Expires – Mars 2003                 [Page 16] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   “Data collection from hundreds of different exporting processes MUST 
   be supported.”, as defined in [IPFIX-REQ]. 
   Total Compliance. 
    
   “The collecting process MUST be able to distinguish several hundred 
   exporting processes by their identifiers.”, as defined in [IPFIX-
   REQ]. 
   Total Compliance, the identifier being the IP address of the 
   exporting process. 

3.7.3 Several Collecting Processes (8.3) 
    
   Total Compliance. The exporting process is able to export flow 
   information to two different collecting process. 

4. Security Considerations 
    
   Security considerations for the IPFIX protocol are covered by the 
   comparison against the specific Security requirements in the IPFIX 
   requirements document [IPFIX-REQ] where they are specifically 
   addressed by sections 6.3.3 and 10. 
    
   The NetFlow flow record export protocol could be run on the top of 
   IPSEC [IPSEC] to assure security. 

5. References 
    
   [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information 
               Export", draft-ietf-ipfix-reqs-05.txt, work in progress, 
               July 2002. 
    
   [IPFIX-REQ6] J. Quittek et al., "Requirements for IP Flow Information 
               Export", draft-ietf-ipfix-reqs-06.txt, work in progress, 
               July 2002. 
    
   [NETFLOW9]  B. Claise et al., "Cisco Systems NetFlow Services Export  
               Version 9", draft-bclaise-netflow-9-00.txt, work in progress, 
               June 2002. 
    
    [UDP]      J. Postel, "User Datagram Protocol", RFC 768, August  
               1980 
 
    [TCP]      "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM  

Claise                   Expires – Mars 2003                 [Page 17] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

               PROTOCOL SPECIFICATION", RFC 793, September 1981 
 
   [SCTP]     R. Stewart et al, "Stream Control Transmission Protocol",  
              RFC 2960, October 2000 
    
    [IPSEC]    Kent, S., "Security Architecture for the Internet   
               Protocol", RFC 2401, Nov. 1998,  

6. Author's Address 
    
    Benoit Claise 
    Cisco Systems 
    De Kleetlaan 6a b1 
    1831 Diegem 
    Belgium 
 
    Phone: +32 2 704 5622 
    Email: [email-masked] 
    
7. Full Copyright Statement 
    
   Copyright (C) The Internet Society (2001). 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 languages other than 
   English. 
 
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
 
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 

Claise                   Expires – Mars 2003                 [Page 18] 
Evaluation Of NetFlow Version 9 Against IPFIX Requirements    Sept. 2002 

   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

     

 
 
Claise                   Expires – Mars 2003                 [Page 19]