GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5470

Network Working Group G. Sadasivan Request for Comments: 5470 Rohati Systems Category: Informational N. Brownlee

                                    CAIDA | The University of Auckland
                                                             B. Claise
                                                   Cisco Systems, Inc.
                                                            J. Quittek
                                                                   NEC
                                                            March 2009
            Architecture for IP Flow Information Export

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Abstract

 This memo defines the IP Flow Information eXport (IPFIX) architecture
 for the selective monitoring of IP Flows, and for the export of
 measured IP Flow information from an IPFIX Device to a Collector.

Sadasivan, et al. Informational [Page 1] RFC 5470 IPFIX Architecture March 2009

Table of Contents

 1. Introduction ....................................................3
    1.1. Document Scope .............................................3
    1.2. IPFIX Documents Overview ...................................3
 2. Terminology .....................................................4
 3. Examples of Flows ...............................................8
 4. IPFIX Reference Model ..........................................10
 5. IPFIX Functional and Logical Blocks ............................12
    5.1. Metering Process ..........................................12
         5.1.1. Flow Expiration ....................................12
         5.1.2. Flow Export ........................................13
    5.2. Observation Point .........................................13
    5.3. Selection Criteria for Packets ............................13
         5.3.1. Sampling Functions, Si .............................14
         5.3.2. Filter Functions, Fi ...............................15
    5.4. Observation Domain ........................................15
    5.5. Exporting Process .........................................15
    5.6. Collecting Process ........................................16
    5.7. Summary ...................................................17
 6. Overview of the IPFIX Protocol .................................18
    6.1. Information Model Overview ................................19
    6.2. Flow Records ..............................................19
    6.3. Control Information .......................................20
    6.4. Reporting Responsibilities ................................21
 7. IPFIX Protocol Details .........................................21
    7.1. The IPFIX Basis Protocol ..................................21
    7.2. IPFIX Protocol on the Collecting Process ..................22
    7.3. Support for Applications ..................................22
 8. Export Models ..................................................23
    8.1. Export with Reliable Control Connection ...................23
    8.2. Collector Failure Detection and Recovery ..................23
    8.3. Collector Redundancy ......................................24
 9. IPFIX Flow Collection in Special Situations ....................24
 10. Security Considerations .......................................25
    10.1. Data Security ............................................25
         10.1.1. Host-Based Security ...............................26
         10.1.2. Authentication-Only ...............................26
         10.1.3. Encryption ........................................26
    10.2. IPFIX End-Point Authentication ...........................27
    10.3. IPFIX Overload ...........................................27
         10.3.1. Denial-of-Service (DoS) Attack Prevention .........27
 11. IANA Considerations ...........................................28
    11.1. Numbers Used in the Protocol .............................28
    11.2. Numbers Used in the Information Model ....................29
 12. Acknowledgements ..............................................29

Sadasivan, et al. Informational [Page 2] RFC 5470 IPFIX Architecture March 2009

 13. References ....................................................30
    13.1. Normative References .....................................30
    13.2. Informative References ...................................30

1. Introduction

 There are several applications, e.g., usage-based accounting, traffic
 profiling, traffic engineering, attack/intrusion detection, quality-
 of-service (QoS) monitoring, that require Flow-based IP traffic
 measurements.  It is therefore important to have a standard way of
 exporting information related to IP Flows.  This document defines an
 architecture for IP traffic Flow monitoring, measuring, and
 exporting.  It provides a high-level description of an IPFIX Device's
 key components and their functions.

1.1. Document Scope

 This document defines the architecture for IPFIX.  Its main
 objectives are to:
 o  Describe the key IPFIX architectural components, consisting of (at
    least) IPFIX Devices and Collectors communicating using the IPFIX
    protocol.
 o  Define the IPFIX architectural requirements, e.g., recovery,
    security, etc.
 o  Describe the characteristics of the IPFIX protocol.

1.2. IPFIX Documents Overview

 The IPFIX protocol provides network administrators with access to IP
 Flow information.  This document specifies the architecture for the
 export of measured IP Flow information from an IPFIX Exporting
 Process to a Collecting Process, per the requirements defined in RFC
 3917 [1].  The IPFIX protocol document, RFC 5101 [3], specifies how
 IPFIX data records and templates are carried via a congestion-aware
 transport protocol, from IPFIX Exporting Process to IPFIX Collecting
 Process.  IPFIX has a formal description of IPFIX information
 elements (fields), their name, type, and additional semantic
 information, as specified in RFC 5102 [2].  Finally, RFC 5472 [4]
 describes what type of applications can use the IPFIX protocol and
 how they can use the information provided.  Furthermore, it shows how
 the IPFIX framework relates to other architectures and frameworks.
 Note that the IPFIX system does not provide for remote configuration
 of an IPFIX device.  Instead, implementors must provide an effective
 way to configure their IPFIX devices.

Sadasivan, et al. Informational [Page 3] RFC 5470 IPFIX Architecture March 2009

2. Terminology

 The definitions of basic IPFIX terms such as IP Traffic Flow,
 Exporting Process, Collecting Process, Observation Point, etc., are
 semantically identical with those found in the IPFIX requirements
 document, RFC 3917 [1].  Some of the terms have been expanded for
 more clarity when defining the protocol.  Additional definitions
 required for the architecture have also been defined.  For terms that
 are defined here and in RFC 5101 [3], the definitions are equivalent
 in both documents.
  • Observation Point
    An Observation Point is a location in the network where IP packets
    can be observed.  Examples include: a line to which a probe is
    attached, a shared medium, such as an Ethernet-based LAN, a single
    port of a router, or a set of interfaces (physical or logical) of
    a router.
    Note that every Observation Point is associated with an
    Observation Domain (defined below), and that one Observation Point
    may be a superset of several other Observation Points.  For
    example, one Observation Point can be an entire line card.  That
    would be the superset of the individual Observation Points at the
    line card's interfaces.
  • Observation Domain
    An Observation Domain is the largest set of Observation Points for
    which Flow information can be aggregated by a Metering Process.
    For example, a router line card may be an Observation Domain if it
    is composed of several interfaces, each of which is an Observation
    Point.  In the IPFIX Message it generates, the Observation Domain
    includes its Observation Domain ID, which is unique per Exporting
    Process.  That way, the Collecting Process can identify the
    specific Observation Domain from the Exporter that sends the IPFIX
    Messages.  Every Observation Point is associated with an
    Observation Domain.  It is recommended that Observation Domain IDs
    also be unique per IPFIX Device.
  • IP Traffic Flow or Flow
    There are several definitions of the term 'flow' being used by the
    Internet community.  Within the context of IPFIX we use the
    following definition:

Sadasivan, et al. Informational [Page 4] RFC 5470 IPFIX Architecture March 2009

    A Flow is defined as a set of IP 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:
    1.  one or more packet header fields (e.g., destination IP
        address), transport header fields (e.g., destination port
        number), or application header fields (e.g., RTP header fields
        [5]).
    2.  one or more characteristics of the packet itself (e.g., number
        of MPLS labels)
    3.  one or more fields derived from packet treatment (e.g., next
        hop IP address, output interface)
    A packet is defined as belonging to a Flow if it completely
    satisfies all the defined properties of the Flow.
    This definition covers the range from a Flow containing all
    packets observed at a network interface to a Flow consisting of
    just a single packet between two applications.  It includes
    packets selected by a sampling mechanism.
  • Flow Key
    Each of the fields that:
    1.  belongs to the packet header (e.g., destination IP address),
    2.  is a property of the packet itself (e.g., packet length),
    3.  is derived from packet treatment (e.g., Autonomous System (AS)
        number), and
    4.  is used to define a Flow
    is termed a Flow Key.
  • Flow Record
    A Flow Record contains information about a specific Flow that was
    observed at an Observation Point.  A Flow Record contains measured
    properties of the Flow (e.g., the total number of bytes for all
    the Flow's packets) and usually characteristic properties of the
    Flow (e.g., source IP address).

Sadasivan, et al. Informational [Page 5] RFC 5470 IPFIX Architecture March 2009

  • Metering Process
    The Metering Process generates Flow Records.  Inputs to the
    process are packet headers and characteristics observed at an
    Observation Point, and packet treatment at the Observation Point
    (for example, the selected output interface).
    The Metering Process consists of a set of functions that includes
    packet header capturing, timestamping, sampling, classifying, and
    maintaining Flow Records.
    The maintenance of Flow Records may include creating new records,
    updating existing ones, computing Flow statistics, deriving
    further Flow properties, detecting Flow expiration, passing Flow
    Records to the Exporting Process, and deleting Flow Records.
  • Exporting Process
    The Exporting Process sends Flow Records to one or more Collecting
    Processes.  The Flow Records are generated by one or more Metering
    Processes.
  • Exporter
    A device that hosts one or more Exporting Processes is termed an
    Exporter.
  • IPFIX Device
    An IPFIX Device hosts at least one Exporting Process.  It may host
    further Exporting Processes and arbitrary numbers of Observation
    Points and Metering Processes.
  • Collecting Process
    A Collecting Process receives Flow Records from one or more
    Exporting Processes.  The Collecting Process might process or
    store received Flow Records, but such actions are out of scope for
    this document.
  • Collector
    A device that hosts one or more Collecting Processes is termed a
    Collector.

Sadasivan, et al. Informational [Page 6] RFC 5470 IPFIX Architecture March 2009

  • Template
    A Template is an ordered sequence of <type, length> pairs used to
    completely specify the structure and semantics of a particular set
    of information that needs to be communicated from an IPFIX Device
    to a Collector.  Each Template is uniquely identifiable by means
    of a Template ID.
  • Control Information, Data Stream
    The information that needs to be exported from the IPFIX Device
    can be classified into the following categories:
    Control Information
       This includes the Flow definition, selection criteria for
       packets within the Flow sent by the Exporting Process, and
       templates describing the data to be exported.  Control
       Information carries all the information needed for the end-
       points to understand the IPFIX protocol, and specifically for
       the Collector to understand and interpret the data sent by the
       sending Exporter.
    Data Stream
       This includes Flow Records carrying the field values for the
       various observed Flows at each of the Observation Points.
  • IPFIX Message
    An IPFIX Message is a message originating at the Exporting Process
    that carries the IPFIX records of this Exporting Process and whose
    destination is a Collecting Process.  An IPFIX Message is
    encapsulated at the transport layer.
  • Information Element
    An Information Element is a protocol and encoding-independent
    description of an attribute that may appear in an IPFIX Record.
    The IPFIX information model, RFC 5102 [2], defines the base set of
    Information Elements for IPFIX.  The type associated with an
    Information Element indicates constraints on what it may contain
    and also determines the valid encoding mechanisms for use in
    IPFIX.

Sadasivan, et al. Informational [Page 7] RFC 5470 IPFIX Architecture March 2009

3. Examples of Flows

 Some examples of Flows are listed below.  In the IPv4 examples, we
 use interface addresses in three different 26-bit (/26) subnets.  In
 the IPv6 examples, we use 'mac addr-nn' in the low-order 64 bits to
 indicate the IEEE MAC (Media Access Control) address of host
 interface nn.
 Example 1: Flow Keys define the different fields by which Flows are
 distinguished.  The different combination of their field values
 creates unique Flows.  If {source IP address, destination IP address,
 DSCP} are Flow Keys, then all of these are different Flows:
   1. {192.0.2.1,   192.0.2.65, 4}
   2. {192.0.2.23,  192.0.2.67, 4}
   3. {192.0.2.23,  192.0.2.67, 2}
   4. {192.0.2.129, 192.0.2.67, 4}
   5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4}
   6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4}
   7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2}
   8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4}
 Example 2: A mask function can be applied to all the packets that
 pass through an Observation Point, in order to aggregate some values.
 This could be done by defining the set of Flow Keys as {source IP
 address, destination IP address, DSCP} as in Example 1 above, and
 applying functions that mask out the source and destination IP
 addresses (least significant 6 bits for IPv4, 64 bits for IPv6).  The
 eight Flows from Example 1 would now be aggregated into six Flows by
 merging the Flows 1+2 and 5+6 into single Flows:
   1. {192.0.2.0/26,   192.0.2.64/26, 4}
   2. {192.0.2.0/26,   192.0.2.64/26, 2}
   3. {192.0.2.128/26, 192.0.2.64/26, 4}
   4. {2001:DB8::0/64, 2001:DB8::1/64, 4}
   5. {2001:DB8::0/64, 2001:DB8::1/64, 2}
   6. {2001:DB8::2/64, 2001:DB8::1/64, 4}
 Example 3: A filter defined by some Flow Key values can be applied 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 Keys from the packet.
 All the packets that go from a customer network 192.0.2.0/26 to
 another customer network 192.0.2.64/26 with DSCP value of 4 define a
 Flow.  All other combinations don't define a Flow and are not taken

Sadasivan, et al. Informational [Page 8] RFC 5470 IPFIX Architecture March 2009

 into account.  The three Flows from Example 2 would now be reduced to
 one Flow by filtering out Flows 2 and 3, leaving only Flow 1,
 {192.0.2.0/26, 192.0.2.64/26, 4}.
 Similarly, for the IPv6 packets in the examples above, one could
 filter out Flows 5 and 6 to leave Flow 4.
 The above examples can be thought of as a function F() taking as
 input {source IP address, destination IP address, DSCP}.  The
 function selects only the packets that satisfy all three of the
 following conditions:
 1.  Mask out the least significant 6 bits of source IP address, match
     against 192.0.2.0.
 2.  Mask out the least significant 6 bits of destination IP address,
     match against 192.0.2.64.
 3.  Only accept DSCP value equal to 4.
 Depending on the values of {source IP address, destination IP
 address, DSCP} of the different observed packets, the Metering
 Process function F() would choose/filter/aggregate different sets of
 packets, which would create different Flows.  For example, for
 various combinations of values of {source IP address, destination IP
 address, DSCP}, F(source IP address, destination IP address, DSCP)
 would result in the definition of one or more Flows.

Sadasivan, et al. Informational [Page 9] RFC 5470 IPFIX Architecture March 2009

4. IPFIX Reference Model

 The figure below shows the reference model for IPFIX.  This figure
 covers the various possible scenarios that can exist in an IPFIX
 system.
                           +----------------+     +----------------+
                           |[*Application 1]| ... |[*Application n]|
                           +--------+-------+     +-------+--------+
                                    ^                     ^
                                    |                     |
                                    + = = = = -+- = = = = +
                                               ^
                                               |
 +------------------------+            +-------+------------------+
 |IPFIX Exporter          |            | Collector(1)             |
 |[Exporting Process(es)] |<---------->| [Collecting Process(es)] |
 +------------------------+            +--------------------------+
         ....                                  ....
 +------------------------+           +---------------------------+
 |IPFIX Device(i)         |           | Collector(j)              |
 |[Observation Point(s)]  |<--------->| [Collecting Process(es)]  |
 |[Metering Process(es)]  |     +---->| [*Application(s)]         |
 |[Exporting Process(es)] |     |     +---------------------------+
 +------------------------+     .
        ....                    .              ....
 +------------------------+     |     +--------------------------+
 |IPFIX Device(m)         |     |     | Collector(n)             |
 |[Observation Point(s)]  |<----+---->| [Collecting Process(es)] |
 |[Metering Process(es)]  |           | [*Application(s)]        |
 |[Exporting Process(es)] |           +--------------------------+
 +------------------------+
 The various functional components are indicated within brackets [].
 The functional components within [*] are not part of the IPFIX
 architecture.  The interfaces shown by "<----->" are defined by the
 IPFIX architecture, but those shown by "<= = = =>" are not.
                    Figure 1: IPFIX Reference Model

Sadasivan, et al. Informational [Page 10] RFC 5470 IPFIX Architecture March 2009

 The figure below shows a typical IPFIX Device where the IPFIX
 components are shown in rectangular boxes.
         +--------------------------------------------------+
         |                 IPFIX Device                     |
         |                                          +-----+ |
         |        +------- ... ------------+--------->    | |
         |        |                        |        |     | |
         |   +----+----+              +----+----+   |     | |
         |   |Metering |              |Metering |   |  E  | |
         |   |Process 1|              |Process N|   |  x  | |
         |   +---------+              +---------+   |  p  | |
         |        ^                        ^        |  o  | |
         | +------+--------+     +---------+------+ |  r  | |
         | | Obsv Domain 1 |     | Obsv Domain N  | |  t  | |
         | |+-----+-------+|     |+-------+------+| |  i  | |
         | ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| |  n  | |
         | |+-------------+|     |+--------------+| |  g  | | Export
 Packets | +------^--------+     +---------^------+ |     | | packets
 --->----+--------+---------- ... ---------+        |     | |   to
    In   |                                          |     +--------->
         |        . . . . .                         |     | |Collector
         |                                          |     | |
         |        +------ ... -------------+--------->    | |
         |        |                        |        |     | |
         |   +----+----+              +----+----+   |  P  | |
         |   |Metering |              |Metering |   |  r  | |
         |   |Process 1|              |Process N|   |  o  | |
         |   +---------+              +---------+   |  c  | |
         |        ^                        ^        |  e  | |
         | +------+--------+     +---------+------+ |  s  | |
         | | Obsv Domain 1 |     | Obsv Domain N  | |  s  | |
         | |+-----+-------+|     |+-------+------+| |     | |
         | ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| |     | |
         | |+-------------+|     |+--------------+| |     | |
 Packets | +------^--------+     +---------^------+ +-----+ |
 --->----+--------+---------- ... ---------+                |
    In   |                                                  |
         +--------------------------------------------------+
                        Figure 2: IPFIX Device

Sadasivan, et al. Informational [Page 11] RFC 5470 IPFIX Architecture March 2009

5. IPFIX Functional and Logical Blocks

5.1. Metering Process

 Every Observation Point in an IPFIX Device, participating in Flow
 measurements, must be associated with at least one Metering Process.
 Every packet coming into an Observation Point goes into each of the
 Metering Processes associated with the Observation Point.  Broadly,
 each Metering Process observes the packets that pass an Observation
 Point, does timestamping, and classifies the packets into Flow(s)
 based on the selection criteria.
 The Metering Process is a functional block that manages all the Flows
 generated from an Observation Domain.  The typical functions of a
 Metering Process may include:
 o  Maintaining database(s) of all the Flow Records from an
    Observation Domain.  This includes creating new Flow Records,
    updating existing ones, computing Flow Records statistics,
    deriving further Flow properties, and adding non-Flow-specific
    information based on the packet treatment (in some cases, fields
    like AS numbers, router state, etc.)
 o  Maintaining statistics about the Metering Process itself, such as
    Flow Records generated, packets observed, etc.

5.1.1. Flow Expiration

 A Flow is considered to have expired under the following conditions:
 1.  If no packets belonging to the Flow have been observed for a
     certain period of time.  This time period should be configurable
     at the Metering Process, with a minimum value of 0 seconds for
     immediate expiration.  Note that a zero timeout would report a
     Flow as a sequence of single-packet Flows.
 2.  If the IPFIX Device experiences resource constraints, a Flow may
     be prematurely expired (e.g., lack of memory to store Flow
     Records).
 3.  For long-running Flows, the Metering Process should expire the
     Flow on a regular basis or based on some expiration policy.  This
     periodicity or expiration policy should be configurable at the
     Metering Process.  When a long-running Flow is expired, its Flow
     Record may still be maintained by the Metering Process so that
     the Metering Process does not need to create a new Flow Record
     for further observed packets of the same Flow.

Sadasivan, et al. Informational [Page 12] RFC 5470 IPFIX Architecture March 2009

5.1.2. Flow Export

 The Exporting Process decides when and whether to export an expired
 Flow.  A Flow can be exported because it expired for any of the
 reasons mentioned in Section 5.1.1, "Flow Expiration".  For example:
 the Exporting Process exports a portion of the expired Flows every
 'x' seconds.
 For long-lasting Flows, the Exporting Process should export the Flow
 Records on a regular basis or based on some export policy.  This
 periodicity or export policy should be configurable at the Exporting
 Process.

5.2. Observation Point

 A Flow Record can be better analysed if the Observation Point from
 which it was measured is known.  As such, it is recommended that
 IPFIX Devices send this information to Collectors.  In cases where
 there is a single Observation Point or where the Observation Point
 information is not relevant, the Metering Process may choose not to
 add the Observation Point information to the Flow Records.

5.3. Selection Criteria for Packets

 A Metering Process may define rules so that only certain packets
 within an incoming stream of packets are chosen for measurement at an
 Observation Point.  This may be done by one of the two methods
 defined below or a combination of them, in either order.  A
 combination of each of these methods can be adopted to select the
 packets, i.e., one can define a set of methods {F1, S1, F2, S2, S3}
 executed in a specified sequence at an Observation Point to select
 particular Flows.
 The figure below shows the operations that may be applied as part of
 a typical Metering Process.

Sadasivan, et al. Informational [Page 13] RFC 5470 IPFIX Architecture March 2009

               +---------------------------+
               |  packet header capturing  |
               +---------------------------+
                            |
                            v
               +---------------------------+
               |       timestamping        |
               +---------------------------+
                            |
                            v
          +---------------> +
          |                 |
          |                 v
          |    +----------------------------------------------+
          |    |   sampling Si (1:1 in case of no sampling)   |
          |    +----------------------------------------------+
          |                 |
          |                 v
          |    +----------------------------------------------+
          |    |  filtering Fi (select all when no criteria)  |
          |    +----------------------------------------------+
          |                 |
          |                 v
          +-----------------+
                            |
                            v
               +---------------------------+
               |          Flows            |
               +---------------------------+
               Figure 3: Selection Criteria for Packets
 Note that packets could be selected before or after any IP
 processing, i.e., before there is any IP checksum validation, IP
 filtering, etc., or after one or more of these steps.  This has an
 impact on what kinds of traffic (or erroneous conditions) IPFIX can
 observe.  It is recommended that packets are selected after their
 checksums have been verified.

5.3.1. Sampling Functions, Si

 A sampling function determines which packets within a stream of
 incoming packets are selected for measurement, i.e., packets that
 satisfy the sampling criteria for this Metering Process.
 Example: sample every 100th packet that was received at an
 Observation Point.

Sadasivan, et al. Informational [Page 14] RFC 5470 IPFIX Architecture March 2009

 Choosing all the packets is a special case where the sampling rate is
 1:1.

5.3.2. Filter Functions, Fi

 A Filter Function selects only those incoming packets that satisfy a
 function on fields defined by the packet header fields, fields
 obtained while doing the packet processing, or properties of the
 packet itself.
 Example: Mask/Match of the fields that define a filter.  A filter
 might be defined as {Protocol == TCP, Destination Port < 1024}.
 Several such filters could be used in any sequence to select packets.
 Note that packets selected by a (sequence of) filter functions may be
 further classified by other filter functions, i.e., the selected
 packets may belong to several Flows, any or all of which are
 exported.

5.4. Observation Domain

 The Observation Domain is a logical block that presents a single
 identity for a group of Observation Points within an IPFIX Device.
 Each {Observation Point, Metering Process} pair belongs to a single
 Observation Domain.  An IPFIX Device could have multiple Observation
 Domains, each of which has a subset of the total set of Observation
 Points in it.  Each Observation Domain must carry a unique ID within
 the context of an IPFIX Device.  Note that in the case of multiple
 Observation Domains, a unique ID per Observation Domain must be
 transmitted as a parameter to the Exporting Function.  That unique ID
 is referred to as the IPFIX Observation Domain ID.

5.5. Exporting Process

 The Exporting Process is the functional block that sends data to one
 or more IPFIX Collectors using the IPFIX protocol.  On one side, the
 Exporting Process interfaces with Metering Process(es) to get Flow
 Records; while on the other side, it talks to a Collecting Process on
 the Collector(s).
 There may be additional rules defined within an Observation Domain so
 that only certain Flow Records are exported.  This may be done by
 either one or a combination of Si and Fi, as described in
 Section 5.3, "Selection Criteria for Packets".
 Example: Only the Flow Records that meet the following selection
 criteria are exported:

Sadasivan, et al. Informational [Page 15] RFC 5470 IPFIX Architecture March 2009

 1.  All Flow Records whose destination IP address matches
     {192.0.33.5}.
 2.  Every other (i.e., sampling rate 1 in 2) Flow Record whose
     destination IP address matches {192.0.11.30}.

5.6. Collecting Process

 Collecting Processes use a Flow Record's Template ID to interpret
 that Flow Record's Information Elements.  To allow this, an IPFIX
 Exporter must ensure that an IPFIX Collector knows the Template ID
 for each incoming Flow Record.  To interpret incoming Flow Records,
 an IPFIX Collector may also need to know the function F() that was
 used by the Metering Process for each Flow.
 The functions of the Collecting Process must include:
 o  Identifying, accepting, and decoding the IPFIX Messages from
    different <Exporting Process, Observation Domain> pairs.
 o  Storing the Control Information and Flow Records received from an
    IPFIX Device.
 At a high level, the Collecting Process:
 1.  Receives and stores the Control Information.
 2.  Decodes and stores the Flow Records using the Control
     Information.

Sadasivan, et al. Informational [Page 16] RFC 5470 IPFIX Architecture March 2009

5.7. Summary

 The figure below shows the functions performed in sequence by the
 various functional blocks in an IPFIX Device.
                  Packet(s) coming into Observation Point(s)
                    |                                   |
                    v                                   v
   +----------------+-------------------------+   +-----+-------+
   |          Metering Process on an          |   |             |
   |             Observation Point            |   |             |
   |                                          |   |             |
   |   packet header capturing                |   |             |
   |        |                                 |...| Metering    |
   |   timestamping                           |   | Process N   |
   |        |                                 |   |             |
   | +----->+                                 |   |             |
   | |      |                                 |   |             |
   | |   sampling Si (1:1 in case of no       |   |             |
   | |      |          sampling)              |   |             |
   | |   filtering Fi (select all when        |   |             |
   | |      |          no criteria)           |   |             |
   | +------+                                 |   |             |
   |        |                                 |   |             |
   |        |        Timing out Flows         |   |             |
   |        |    Handle resource overloads    |   |             |
   +--------|---------------------------------+   +-----|-------+
            |                                           |
    Flow Records (identified by Observation Domain)  Flow Records
            |                                           |

Sadasivan, et al. Informational [Page 17] RFC 5470 IPFIX Architecture March 2009

            +---------+---------------------------------+
                      |
 +--------------------|----------------------------------------------+
 |                    |     Exporting Process                        |
 |+-------------------|-------------------------------------------+  |
 ||                   v       IPFIX Protocol                      |  |
 ||+-----------------------------+  +----------------------------+|  |
 |||Rules for                    |  |Functions                   ||  |
 ||| Picking/sending Templates   |  |-Packetise selected Control ||  |
 ||| Picking/sending Flow Records|->|  & data Information into   ||  |
 ||| Encoding Template & data    |  |  IPFIX export packets.     ||  |
 ||| Selecting Flows to export(*)|  |-Handle export errors       ||  |
 ||+-----------------------------+  +----------------------------+|  |
 |+----------------------------+----------------------------------+  |
 |                             |                                     |
 |                    exported IPFIX Messages                        |
 |                             |                                     |
 |                +------------+-----------------+                   |
 |                |  Anonymise export packet(*)  |                   |
 |                +------------+-----------------+                   |
 |                             |                                     |
 |                +------------+-----------------+                   |
 |                |       Transport  Protocol    |                   |
 |                +------------+-----------------+                   |
 |                             |                                     |
 +-----------------------------+-------------------------------------+
                               |
                               v
                  IPFIX export packet to Collector
 (*) indicates that the block is optional.
               Figure 4: IPFIX Device functional blocks

6. Overview of the IPFIX Protocol

 An IPFIX Device consists of a set of cooperating processes that
 implement the functional blocks described in the previous section.
 Alternatively, an IPFIX Device can be viewed simply as a network
 entity that implements the IPFIX protocol.  At the IPFIX Device, the
 protocol functionality resides in the Exporting Process.  The IPFIX
 Exporting Process gets Flow Records from a Metering Process, and
 sends them to the Collector(s).
 At a high level, an IPFIX Device performs the following tasks:
 1.  Encodes Control Information into Templates.

Sadasivan, et al. Informational [Page 18] RFC 5470 IPFIX Architecture March 2009

 2.  Encodes packets observed at the Observation Points into Flow
     Records.
 3.  Packetises the selected Templates and Flow Records into IPFIX
     Messages.
 4.  Sends IPFIX Messages to the Collector.
 The IPFIX protocol communicates information from an IPFIX Exporter to
 an IPFIX Collector.  That information includes not only Flow Records,
 but also information about the Metering Process.  Such information
 (referred to as Control Information) includes details of the data
 fields in Flow Records.  It may also include statistics from the
 Metering Process, such as the number of packets lost (i.e., not
 metered).
 For details of the IPFIX protocol, please refer to RFC 5101 [3].

6.1. Information Model Overview

 The IP Flow Information eXport (IPFIX) protocol serves for
 transmitting information related to measured IP traffic over the
 Internet.  The protocol specification in RFC 5101 [3] defines how
 Information Elements are transmitted.  For Information Elements, it
 specifies the encoding of a set of basic data types.  However, the
 list of fields that can be transmitted by the protocol, such as Flow
 attributes (source IP address, number of packets, etc.) and
 information about the Metering and Exporting Process (packet
 Observation Point, sampling rate, Flow timeout interval, etc.), is
 not specified in RFC 5101 [3].  Instead, it is defined in the IPFIX
 information model in RFC 5102 [2].
 The information model provides a complete description of the
 properties of every IPFIX Information Element.  It does this by
 specifying each element's name, Field Type, data type, etc., and
 providing a description of each element.  Element descriptions give
 the semantics of the element, i.e., say how it is derived from a Flow
 or other information available within an IPFIX Device.

6.2. Flow Records

 The following rules provide guidelines to be followed while encoding
 the Flow Records information:
 A Flow Record contains enough information so that the Collecting
 Process can identify the corresponding <Per-Flow Control Information,
 Configuration Control Information>.

Sadasivan, et al. Informational [Page 19] RFC 5470 IPFIX Architecture March 2009

 The Exporting Process encodes a given Information Element (as
 specified in RFC 5102 [2]), based on the encoding standards
 prescribed by RFC 5101 [3].

6.3. Control Information

 The following rules provide guidelines to be followed while encoding
 the Control Information:
 o  Per-Flow Control Information should be encoded such that the
    Collecting Process can capture the structure and semantics of the
    corresponding Flow data for each of the Flow Records exported by
    the IPFIX Device.
 o  Configuration Control Information is conveyed to a Collector so
    that its Collecting Process can capture the structure and
    semantics of the corresponding configuration data.  The
    configuration data, which is also Control Information, should
    carry additional information on the Observation Domain within
    which the configuration takes effect.
 For example, sampling using the same sampling algorithm, say 1 in 100
 packets, is configured on two Observation Points O1 and O2.  The
 configuration in this case may be encoded as {ID, observation points
 (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is the
 Observation Domain ID for the domain containing O1 and O2.  The
 Observation Domain ID uniquely identifies this configuration, and
 must be sent within the Flow Records in order to be able to match the
 right configuration control information.
 The Control Information is used by the Collecting Process to:
 o  Decode and interpret Flow Records.
 o  Understand the state of the Exporting Process.
 Sending Control Information from the Exporting Process in a timely
 and reliable manner is critical to the proper functioning of the
 IPFIX Collecting Process.  The following approaches may be taken for
 the export of Control Information:
 1.  Send all the Control Information pertaining to Flow Records prior
     to sending the Flow Records themselves.  This includes any
     incremental changes to the definition of the Flow Records.

Sadasivan, et al. Informational [Page 20] RFC 5470 IPFIX Architecture March 2009

 2.  Notify, on a near real-time basis, the state of the IPFIX Device
     to the Collecting Process.  This includes all changes such as a
     configuration change that affects the Flow behaviour, changes to
     Exporting Process resources that alter export rates, etc., which
     the Collector needs to be aware of.
 3.  Since it is vital that a Collecting Process maintains accurate
     knowledge of the Exporter's state, the export of the Control
     Information should be done such that it reaches the Collector
     reliably.  One way to achieve this is to send the Control
     Information over a reliable transport.

6.4. Reporting Responsibilities

 From time to time, an IPFIX Device may not be able to observe all the
 packets reaching one of its Observation Points.  This could occur if
 a Metering Process finds itself temporarily short of resources.  For
 example, it might run out of packet buffers for IPFIX export.
 In such situations, the IPFIX Device should attempt to count the
 number of packet losses that have occurred, and report them to its
 Collector(s).  If it is not possible to count losses accurately,
 e.g., when transport layer (i.e., non-IPFIX) errors are detected, the
 IPFIX Device should report this fact, and perhaps indicate the time
 period during which some packets might not have been observed.

7. IPFIX Protocol Details

 When the IPFIX Working Group was chartered, there were existing
 common practices in the area of Flow export, for example, NetFlow,
 CRANE (Common Reliable Accounting for Network Element), LFAP (Light-
 weight Flow Admission Protocol), RTFM (Real-time Traffic Flow
 Measurement), etc.  IPFIX's charter required the Working Group to
 consider those existing practices, and select the one that was the
 closest fit to the IPFIX requirements in RFC 3917 [1].  Additions or
 modifications would then be made to the selected protocol to fit it
 exactly into the IPFIX architecture.

7.1. The IPFIX Basis Protocol

 The Working Group went through an extensive evaluation of the various
 existing protocols that were available, weighing the level of
 compliance with the requirements, and selected one of the candidates
 as the basis for the IPFIX protocol.  For more details of the
 evaluation process, please see RFC 3955 [6].

Sadasivan, et al. Informational [Page 21] RFC 5470 IPFIX Architecture March 2009

 In the basis protocol, Flow Records are defined by Templates, where a
 Template is an ordered set of the Information Elements appearing in a
 Flow Record, together with their field sizes within those records.
 This approach provides the following advantages:
 o  Using the Template mechanism, new fields can be added to IPFIX
    Flow Records without changing the structure of the export record
    format.
 o  Templates that are sent to the Collecting Process carry structural
    information about the exported Flow Record fields.  Therefore, if
    the Collector does not understand the semantics of new fields, it
    can ignore them, but still interpret the Flow Record.
 o  Because the template mechanism is flexible, it allows the export
    of only the required fields from the Flows to the Collecting
    Process.  This helps to reduce the exported Flow data volume and
    possibly provide memory savings at the Exporting Process and
    Collecting Process.  Sending only the required information can
    also reduce network load.

7.2. IPFIX Protocol on the Collecting Process

 The Collecting Process is responsible for:
 1.  Receiving and decoding Flow Records from the IPFIX Devices.
 2.  Reporting on the loss of Flow Records sent to the Collecting
     Process by an IPFIX Exporting Process.
 Complete details of the IPFIX protocol are given in RFC 5101 [3].

7.3. Support for Applications

 Applications that use the information collected by IPFIX may be
 Billing or Intrusion Detection sub-systems, etc.  These applications
 may be an integral part of the Collecting Process, or they may be co-
 located with the Collecting Process.  The way by which these
 applications interface with IPFIX systems to get the desired
 information is out of scope for this document.

Sadasivan, et al. Informational [Page 22] RFC 5470 IPFIX Architecture March 2009

8. Export Models

8.1. Export with Reliable Control Connection

 As mentioned in RFC 3917 [1], an IPFIX Device must be able to
 transport its Control Information and Data Stream over a congestion-
 aware transport protocol.
 If the network in which the IPFIX Device and Collecting Process are
 located does not guarantee reliability, at least the Control
 Information should be exported over a reliable transport.  The Data
 Stream may be exported over a reliable or unreliable transport
 protocol.
 Possible transport protocols include:
 o  SCTP: Supports reliable and unreliable transport.
 o  TCP: Provides reliable transport only.
 o  UDP: Provides unreliable transport only.  Network operators would
    need to avoid congestion by keeping traffic within their own
    administrative domains.  For example, one could use a dedicated
    network (or Ethernet link) to carry IPFIX traffic from Exporter to
    Collector.

8.2. Collector Failure Detection and Recovery

 The transport connection (in the case of a connection-oriented
 protocol) is pre-configured between the IPFIX Device and the
 Collector.  The IPFIX protocol does not provide any mechanism for
 configuring the Exporting and Collecting Processes.
 Once connected, an IPFIX Collector receives Control Information and
 uses that information to interpret Flow Records.  The IPFIX Device
 should set a keepalive (e.g., the keepalive timeout in the case of
 TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently
 low value so that it can quickly detect a Collector failure.  Note,
 however, that extremely short keepalive intervals can incorrectly
 abort the connection during transient periods of congestion.  They
 can also cause some level of additional network load during otherwise
 idle periods.
 Collector failure refers to the crash or restart of the Collecting
 Process or of the Collector itself.  A Collector failure is detected
 at the IPFIX Device by the break in the connection-oriented transport
 protocol session; depending on the transport protocol, the connection
 timeout mechanisms differ.  On detecting a keepalive timeout in a

Sadasivan, et al. Informational [Page 23] RFC 5470 IPFIX Architecture March 2009

 single Collector scenario, the IPFIX Device should stop sending Flow
 Records to the Collector and try to reestablish the transport
 connection.  If Collecting Process failover is supported by the
 Exporting Process, backup session(s) may be opened in advance, and
 Control Information sent to the failover Collecting Process.
 There could be one or more secondary Collectors with priority
 assigned to them.  The primary Collector crash is detected at the
 IPFIX Device.  On detecting loss of connectivity, the IPFIX Device
 opens a Data Stream with the secondary Collector of the next highest
 priority.  If that secondary was not opened in advance, both the
 Control Information and Data Stream must be sent to it.  That
 Collector might then become the primary, or the Exporting Process
 might try to reestablish the original session.

8.3. Collector Redundancy

 Configuring redundant Collectors is an alternative to configuring
 backup Collectors.  In this model, all Collectors simultaneously
 receive the Control Information and Data Streams.  Multiple {Control
 Information, Data Stream} pairs could be sent, each to a different
 Collector, from the same IPFIX Device.  Since the IPFIX protocol
 requires a congestion-aware transport, achieving redundancy using
 multicast is not an option.

9. IPFIX Flow Collection in Special Situations

 An IPFIX Device can generate, receive, and/or alter two special types
 of traffic, which are listed below.
 Tunnel traffic:
    The IPFIX Device could be the head, midpoint, or end-point of a
    tunnel.  In such cases, the IPFIX Device could be handling Generic
    Routing Encapsulation (GRE) [8], IPinIP [7], or Layer Two
    Tunneling Protocol version 3 [9] traffic.
 VPN traffic:
    The IPFIX Device could be a provider-edge device that receives
    traffic from customer sites belonging to different Virtual Private
    Networks.
 Similarly, IPFIX could be implemented on devices which perform one or
 more of the following special services:

Sadasivan, et al. Informational [Page 24] RFC 5470 IPFIX Architecture March 2009

 o  Explicitly drop packets.  For example, a device that provides
    firewall service drops packets based on some administrative
    policy.
 o  Alter the values of fields used as IPFIX Flow Keys of interest.
    For example, a device that provides NAT service can change the
    source and/or destination IP address.
 In cases such as those listed above, there should be clear guidelines
 as to:
 o  How and when to classify the packets as Flows in the IPFIX Device.
 o  If multiple encapsulations are used to define Flows, how to convey
    the same fields (e.g., IP address) in different layers.
 o  How to differentiate Flows based on different private domains.
    For example, overlapping IP addresses in Layer-3 VPNs.
 o  What extra information needs to be exported so that the Collector
    can make a clear interpretation of the received Flow Records.

10. Security Considerations

 Flow information can be used for various purposes, such as usage-
 based accounting, traffic profiling, traffic engineering, and
 intrusion detection.  The security requirements may differ
 significantly for such applications.  To be able to satisfy the
 security needs of various IPFIX users, an IPFIX system must provide
 different levels of security protection.

10.1. Data Security

 IPFIX data comprises Control Information and Data Streams generated
 by the IPFIX Device.
 The IPFIX data may exist in both the IPFIX Device and the Collector.
 In addition, the data is also transferred on the wire from the IPFIX
 Device to the Collector when it is exported.  To provide security,
 the data should be protected from common network attacks.
 The protection of IPFIX data within the end system (IPFIX Device and
 Collector) is out of scope for this document.  It is assumed that the
 end system operator will provide adequate security for the IPFIX
 data.

Sadasivan, et al. Informational [Page 25] RFC 5470 IPFIX Architecture March 2009

 The IPFIX architecture must allow different levels of protection to
 the IPFIX data on the wire.  Wherever security functions are
 required, it is recommended that users should leverage lower layers
 using either TLS or DTLS (Datagram Transport Layer Security), if
 these can successfully satisfy the security requirement of IPFIX data
 protection.
 To protect the data on the wire, three levels of granularity should
 be supported; these are described in the following subsections.

10.1.1. Host-Based Security

 Security may not be required when the transport between the IPFIX
 Device and the Collector is perceived as safe.  This option allows
 the protocol to run most efficiently without extra overhead, and an
 IPFIX system must support it.

10.1.2. Authentication-Only

 Authentication-only protection provides IPFIX users with the
 assurance of data integrity and authenticity.  The data exchanged
 between the IPFIX Device and the Collector is protected by an
 authentication signature.  Any modification of the IPFIX data will be
 detected by the recipient, resulting in the discarding of the
 received data.  However, the authentication-only option doesn't offer
 data confidentiality.
 The IPFIX user should not use authentication-only when sensitive or
 confidential information is being exchanged.  An IPFIX solution
 should support this option.  The authentication-only option should
 provide replay attack protection.  Some means to achieve this level
 of security are:
 o  Encapsulating Security Payload (with a null encryption algorithm)
 o  Transport Layer Security (with a null encryption algorithm)
 o  IP Authentication Header

10.1.3. Encryption

 Data encryption provides the best protection for IPFIX data.  The
 IPFIX data is encrypted at the sender, and only the intended
 recipient can decrypt and have access to the data.  This option must
 be used when the transport between the IPFIX Device and the Collector
 is unsafe, and the IPFIX data needs to be protected.  It is

Sadasivan, et al. Informational [Page 26] RFC 5470 IPFIX Architecture March 2009

 recommended that the underlying transport layer's security functions
 be used for this purpose.  Some means to achieve this level of
 security are:
 o  Encapsulating Security Payload
 o  Transport Layer Security Protocol
 The data encryption option adds overhead to the IPFIX data transfer.
 It may limit the rate that an Exporter can report its Flow Records to
 the Collector, due to the resource requirement for running
 encryption.

10.2. IPFIX End-Point Authentication

 It is important to make sure that the IPFIX Device is talking to the
 "right" Collector rather than to a masquerading Collector.  The same
 logic also holds true from the Collector's point of view, i.e., it
 may want to make sure it is collecting the Flow Records from the
 "right" IPFIX Device.  An IPFIX system should allow the end-point
 authentication capability so that either one-way or mutual
 authentication can be performed between the IPFIX Device and
 Collector.
 The IPFIX architecture should use any existing transport protection
 protocols, such as TLS, to fulfil the authentication requirement.

10.3. IPFIX Overload

 An IPFIX Device could become overloaded under various conditions.
 This may be because of exhaustion of internal resources used for Flow
 generation and/or export.  Such overloading may cause loss of data
 from the Exporting Process, either from lack of export bandwidth
 (possibly caused by an unusually high number of observed Flows) or
 from network congestion in the path from Exporter to Collector.
 IPFIX Collectors should be able to detect the loss of exported Flow
 Records, and should at least record the number of lost Flow Records.

10.3.1. Denial-of-Service (DoS) Attack Prevention

 Since one of the potential usages for IPFIX is for intrusion
 detection, it is important for the IPFIX architecture to support some
 kind of DoS resistance.

Sadasivan, et al. Informational [Page 27] RFC 5470 IPFIX Architecture March 2009

10.3.1.1. Network under Attack

 The network itself may be under attack, resulting in an overwhelming
 number of IPFIX Messages.  An IPFIX system should try to capture as
 much information as possible.  However, when a large number of IPFIX
 Messages are generated in a short period of time, the IPFIX system
 may become overloaded.

10.3.1.2. Generic DoS Attack on the IPFIX Device and Collector

 The IPFIX Device and Collector may be subject to generic DoS attacks,
 just as any system on any open network.  These types of attacks are
 not IPFIX specific.  Preventing and responding to such types of
 attacks are out of the scope of this document.

10.3.1.3. IPFIX-Specific DoS Attack

 There are some specific attacks on the IPFIX portion of the IPFIX
 Device or Collector:
 o  The attacker could overwhelm the Collector with spoofed IPFIX
    Export packets.  One way to solve this problem is to periodically
    synchronise the sequence numbers of the Flow Records between the
    Exporting and Collecting Processes.
 o  The attacker could provide false reports to the Collector by
    sending spoofed packets.
 The problems mentioned above can be solved to a large extent if the
 control packets are encrypted both ways, thereby providing more
 information that the Collector could use to identify and ignore
 spoofed data packets.

11. IANA Considerations

 The IPFIX Architecture, as set out in this document, has two sets of
 assigned numbers, as outlined in the following subsections.

11.1. Numbers Used in the Protocol

 IPFIX Messages, as described in RFC 5101 [3], use two fields with
 assigned values.  These are the IPFIX Version Number, indicating
 which version of the IPFIX Protocol was used to export an IPFIX
 Message, and the IPFIX Set ID, indicating the type for each set of
 information within an IPFIX Message.

Sadasivan, et al. Informational [Page 28] RFC 5470 IPFIX Architecture March 2009

 Values for the IPFIX Version Number and the IPFIX Set ID, together
 with the considerations for assigning them, are defined in RFC 5101
 [3].

11.2. Numbers Used in the Information Model

 Fields of the IPFIX protocol carry information about traffic
 measurement.  They are modelled as elements of the IPFIX information
 model RFC 5102 [2].  Each Information Element describes a field that
 may appear in an IPFIX Message.  Within an IPFIX Message, the field
 type is indicated by its Field Type.
 Values for the IPFIX Information Element IDs, together with the
 considerations for assigning them, are defined in RFC 5102 [2].

12. Acknowledgements

 The document editors wish to thank all the people contributing to the
 discussion of this document on the mailing list, and the design teams
 for many valuable comments.  In particular, the following made
 significant contributions:
    Tanja Zseby
    Paul Calato
    Dave Plonka
    Jeffrey Meyer
    K.C.Norseth
    Vamsi Valluri
    Cliff Wang
    Ram Gopal
    Jc Martin
    Carter Bullard
    Reinaldo Penno
    Simon Leinen
    Kevin Zhang
    Paul Aitken
    Brian Trammell
    Special thanks to Dave Plonka for the multiple thorough reviews.

Sadasivan, et al. Informational [Page 29] RFC 5470 IPFIX Architecture March 2009

13. References

13.1. Normative References

 [1]  Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements
      for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
 [2]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer,
      "Information for Model IP Flow Information Export", RFC 5102,
      January 2008.
 [3]  Claise, B., "Specification of the IP Flow Information Export
      (IPFIX) Protocol for the Exchange of IP Traffic Flow
      Information", RFC 5101, January 2008.
 [4]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX
      Applicability", RFC 5472, March 2009.

13.2. Informative References

 [5]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
      "RTP: A Transport Protocol for Real-Time Applications", STD 64,
      RFC 3550, July 2003.
 [6]  Leinen, S., "Evaluation of Candidate Protocols for IP Flow
      Information Export (IPFIX)", RFC 3955, October 2004.
 [7]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
 [8]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
      "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
 [9]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
      Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

Sadasivan, et al. Informational [Page 30] RFC 5470 IPFIX Architecture March 2009

Authors' Addresses

 Ganesh Sadasivan
 Rohati Systems
 1192 Borregas Ave.
 Sunnyvale, CA  94089
 USA
 EMail: gsadasiv@rohati.com
 Nevil Brownlee
 CAIDA | The University of Auckland
 Private Bag 92019
 Auckland  1142
 New Zealand
 Phone: +64 9 373 7599 x88941
 EMail: n.brownlee@auckland.ac.nz
 Benoit Claise
 Cisco Systems, Inc.
 De Kleetlaan 6a b1
 1831 Diegem
 Belgium
 Phone: +32 2 704 5622
 EMail: bclaise@cisco.com
 Juergen Quittek
 NEC Laboratories Europe, NEC Europe Ltd.
 Kurfuersten-Anlage 36
 Heidelberg  69115
 Germany
 Phone: +49 6221 4342-115
 EMail: quittek@nw.neclab.eu
 URI:   http://www.neclab.eu/

Sadasivan, et al. Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5470.txt · Last modified: 2009/03/31 21:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki