tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5815


Pages: 64
Top     in Index     Prev     Next
 

Definitions of Managed Objects for IP Flow Information Export

Part 1 of 3, p. 1 to 18
None       Next RFC Part

Obsoleted by:    6615


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     T. Dietz, Ed.
Request for Comments: 5815                              NEC Europe, Ltd.
Category: Standards Track                                   A. Kobayashi
ISSN: 2070-1721                                             NTT PF Labs.
                                                               B. Claise
                                                     Cisco Systems, Inc.
                                                                G. Muenz
                                        Technische Universitaet Muenchen
                                                              April 2010


     Definitions of Managed Objects for IP Flow Information Export

Abstract

   This document defines managed objects for IP Flow Information eXport
   (IPFIX).  These objects provide information for monitoring IPFIX
   Exporters and IPFIX Collectors including the basic configuration
   information.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5815.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
   2. IPFIX Documents Overview ........................................3
   3. The Internet-Standard Management Framework ......................4
   4. Terminology .....................................................4
   5. Structure of the IPFIX MIB ......................................4
      5.1. The Transport Session Table ................................4
      5.2. The Template Table .........................................7
      5.3. The Template Definition Table ..............................9
      5.4. The Export Table ..........................................11
      5.5. The Metering Process Table ................................12
      5.6. The Observation Point Table ...............................13
      5.7. The Selection Process Table ...............................14
      5.8. The Statistical Tables ....................................15
           5.8.1. The Transport Session Statistical Table ............15
           5.8.2. The Template Statistical Table .....................15
           5.8.3. The Metering Process Statistical Table .............15
           5.8.4. The Selection Process Statistical Table ............15
   6. Structure of the IPFIX SELECTOR MIB ............................15
      6.1. The Selector Functions ....................................16
   7. Relationship to Other MIB Modules ..............................18
      7.1. Relationship to the ENTITY MIB and IF MIB .................18
      7.2. MIB Modules Required for IMPORTS ..........................18
   8. MIB Definitions ................................................18
      8.1. IPFIX MIB Definition ......................................19
      8.2. IPFIX SELECTOR MIB Definition .............................56
   9. Security Considerations ........................................60
   10. IANA Considerations ...........................................61
   11. Acknowledgments ...............................................61
   12. References ....................................................62
      12.1. Normative References .....................................62
      12.2. Informative References ...................................63

Top      ToC       Page 3 
1.  Introduction

   This document defines two MIB modules for monitoring IP Flow
   Information eXport (IPFIX) Devices including Exporters and
   Collectors.  Most of the objects defined by the IPFIX MIB module MUST
   be implemented.  Some objects MAY be implemented corresponding to the
   functionality implemented in the equipment.  Since the IPFIX
   architecture [RFC5470] foresees the possibility of using Filtering
   and/or Sampling functions to reduce the data volume, this document
   also provides the IPFIX SELECTOR MIB module, which contains the
   standardized selection methods and is controlled by IANA.  The full
   configuration of the IPFIX Metering Process is out of the scope of
   these MIB modules.

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

2.  IPFIX Documents Overview

   The IPFIX protocol provides network administrators with access to IP
   Flow information.  The architecture for the export of measured IP
   Flow information out of an IPFIX Exporting Process to a Collecting
   Process is defined in [RFC5470], per the requirements defined in
   [RFC3917].  The protocol document [RFC5101] specifies how IPFIX Data
   Records and Templates are carried via a congestion-aware transport
   protocol from IPFIX Exporting Processes to IPFIX Collecting
   Processes.  IPFIX has a formal description of IPFIX Information
   Elements, their name, type and additional semantic information, as
   specified in [RFC5102].  Finally, [RFC5472] describes what type of
   applications can use the IPFIX protocol and how they can use the
   information provided.  It furthermore shows how the IPFIX framework
   relates to other architectures and frameworks.

   It is assumed that Flow metering, export, and collection is performed
   according to the IPFIX architecture defined in [RFC5470].  The
   monitored configuration parameters of the export and collection of
   Flow Templates and Data Records is modeled according to [RFC5101].
   Packet selection methods that may be optionally used by the IPFIX
   Metering Process are not considered in this MIB module.  They are
   defined in the Packet Sampling (PSAMP) framework [RFC5474] and
   Sampling techniques [RFC5475] documents.  Nevertheless, the basis for
   defining Sampling and Filtering functions is given with the IPFIX
   SELECTOR MIB module.  Since the PSAMP export protocol [RFC5476] is
   based on the IPFIX protocol, the Sampling and Filtering functions can
   be added to the IPFIX SELECTOR MIB module as needed.

Top      ToC       Page 4 
3.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies MIB
   modules that are compliant to the SMIv2, which is described in STD
   58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
   2580 [RFC2580].

4.  Terminology

   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc. can be found in
   the IPFIX protocol document [RFC5101].

5.  Structure of the IPFIX MIB

   The IPFIX MIB module consists of seven main tables, the Transport
   Session table, the Template table and the corresponding Template
   Definition table, the Export table, the Metering Process table, the
   Observation Point table, and the Selection Process table.  Since the
   IPFIX architecture [RFC5470] foresees the possibility of using
   Filtering and/or Sampling functions to reduce the data volume, the
   MIB module provides the basic objects for these functions with the
   Selection Process table.  The IPFIX SELECTOR MIB module defined in
   the next section provides the standard Filtering and Sampling
   functions that can be referenced in the ipfixSelectionProcessTable.

   All remaining objects contain statistical values for the different
   tables contained in the MIB module.

   The following subsections describe all tables in the IPFIX MIB
   module.

5.1.  The Transport Session Table

   The Transport Session is the basis of the MIB module.  The Transport
   Session table (ipfixTransportSessionTable) contains all Transport
   Sessions between Exporter and Collector.  The table specifies the
   transport layer protocol of the Transport Session and, depending on
   that protocol, further parameters for the Transport Session.  In the
   case of UDP and TCP, these are the source and destination address as

Top      ToC       Page 5 
   well as the source and destination port.  For Stream Control
   Transmission Protocol (SCTP), the table contains the SCTP Assoc Id,
   which is the index for the SCTP association in the SCTP MIB module
   [RFC3873].  The mode of operation of the device, i.e., if the
   Transport Session is used for collecting or exporting is given in the
   ipfixTransportSessionDeviceMode object.  Further on, it contains the
   configured refresh parameters for Templates and Options Templates
   that are used across unreliable connections as UDP.  Finally, the
   IPFIX version that is exported or collected by this Transport Session
   and a status of the Transport Session is given in the table.

   To illustrate the use of the above tables, let us assume the
   following scenario: we have an Exporter on IP address 192.0.2.22 and
   a Collector on IP address 192.0.2.37.  The Exporter uses TCP to
   export Templates and Data Records.  The same Exporter also exports,
   with UDP, to a Collector with the IP address of 192.0.2.44.  This
   would lead to the following Transport Session table on the Exporter:

Top      ToC       Page 6 
    ipfixTransportSessionTable (1)
    |
    +- ipfixTransportSessionEntry (1)
       |
       +- index (5) (ipfixTransportSessionIndex)
       |  +- ipfixTransportSessionIndex (1) = 5
       |  +- ipfixTransportSessionProtocol (2) = 6 (TCP)
       |  +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4)
       |  +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22
       |  +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4)
       |  +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.37
       |  +- ipfixTransportSessionSourcePort (7) = 7653
       |  +- ipfixTransportSessionDestinationPort (8) = 4739
       |  +- ipfixTransportSessionSctpAssocId (9) = 0
       |  +- ipfixTransportSessionDeviceMode (10) = exporting(1)
       |  +- ipfixTransportSessionTemplateRefreshTimeout (11) = 0
       |  +- ipfixTransportSessionOptionTemplateRefreshTimeout (12) = 0
       |  +- ipfixTransportSessionTemplateRefreshPacket (13) = 0
       |  +- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 0
       |  +- ipfixTransportSessionIpfixVersion (15) = 10
       |  +- ipfixTransportSessionStatus (16) = 2 (active)
       .
       .
       .
       +- index (11) (ipfixTransportSessionIndex)
          +- ipfixTransportSessionIndex (1) = 11
          +- ipfixTransportSessionProtocol (2) = 17 (UDP)
          +- ipfixTransportSessionSourceAddressType (3) = 1 (ipv4)
          +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22
          +- ipfixTransportSessionDestinationAddressType (5) = 1 (ipv4)
          +- ipfixTransportSessionDestinationAddress (6) = 192.0.2.44
          +- ipfixTransportSessionSourcePort (7) = 14287
          +- ipfixTransportSessionDestinationPort (8) = 4739
          +- ipfixTransportSessionSctpAssocId (9) = 0
          +- ipfixTransportSessionDeviceMode (10) = exporting(1)
          +- ipfixTransportSessionTemplateRefreshTimeout (11) = 100
          +- ipfixTransportSessionOptionTemplateRefreshTimeout (12)
          |                                                     = 100
          +- ipfixTransportSessionTemplateRefreshPacket (13) = 10
          +- ipfixTransportSessionOptionTemplateRefreshPacket (14) = 10
          +- ipfixTransportSessionIpfixVersion (15) = 10
          +- ipfixTransportSessionStatus (16) = 2 (active)

   The values in brackets are the OID numbers.  The Collectors would
   then have the same entry except that the index would most likely
   differ and the ipfixTransportSessionDeviceMode would be
   collecting(2).

Top      ToC       Page 7 
5.2.  The Template Table

   The Template table lists all Templates (including Options Templates)
   that are sent (by an Exporter) or received (by a Collector).  The
   (Options) Templates are unique per Transport Session, which also
   gives the device mode (Exporter or Collector) and Observation Domain;
   thus, the table is indexed by:

   o  the Transport Session Index (ipfixTransportSessionIndex)

   o  and the Observation Domain Id (ipfixTemplateObservationDomainId).

   It contains the Set Id and an access time denoting the time when the
   (Options) Template was last sent or received.

   To resume the above example, the Exporter may want to export a
   Template and an Options Template for each Transport Session defined
   above.  This leads to the following Template table defining Template
   and Options Template:

Top      ToC       Page 8 
    ipfixTemplateTable (3)
    |
    +- ipfixTemplateEntry (1)
       |
       +- index (5) (ipfixTransportSessionIndex)
       |  +- index (3) (ipfixTemplateObservationDomainId)
       |     + index (257) (ipfixTemplateId)
       |     | +- ipfixTemplateObservationDomainId (1) = 3
       |     | +- ipfixTemplateId (2) = 257
       |     | +- ipfixTemplateSetId (3) = 2
       |     | +- ipfixTemplateAccessTime (4)
       |     |                             = 2008-7-1,12:49:11.2,+2:0
       |     |
       |     + index (264) (ipfixTemplateId)
       |       +- ipfixTemplateObservationDomainId (1) = 3
       |       +- ipfixTemplateId (2) = 264
       |       +- ipfixTemplateSetId (3) = 3
       |       +- ipfixTemplateAccessTime (4)
       .                                   = 2008-7-1,12:47:04.8,+2:0
       .
       .
       .
       +- index (11) (ipfixTransportSessionIndex)
          +- index (3) (ipfixTemplateObservationDomainId)
             + index (273) (ipfixTemplateId)
             | +- ipfixTemplateObservationDomainId (1) = 3
             | +- ipfixTemplateId (2) = 273
             | +- ipfixTemplateSetId (3) = 2
             | +- ipfixTemplateAccessTime (4)
             |                             = 2008-7-1,12:49:11.2,+2:0
             |
             + index (289) (ipfixTemplateId)
               +- ipfixTemplateObservationDomainId (1) = 3
               +- ipfixTemplateId (2) = 289
               +- ipfixTemplateSetId (3) = 3
               +- ipfixTemplateAccessTime (4)
                                           = 2008-7-1,12:47:04.8,+2:0

   We assume that the Transport Session that is stored with index 5 in
   the Transport Session table of the Exporter is stored with index 17
   in the Transport Session table of the (corresponding) Collector.
   Then, the Template table would look as follows:

Top      ToC       Page 9 
    ipfixTemplateTable (3)
    |
    +- ipfixTemplateEntry (1)
       |
       +- index (17) (ipfixTransportSessionIndex)
          +- index (3) (ipfixTemplateObservationDomainId)
             + index (257) (ipfixTemplateId)
             | +- ipfixTemplateObservationDomainId (1) = 3
             | +- ipfixTemplateId (2) = 257
             | +- ipfixTemplateSetId (3) = 2
             | +- ipfixTemplateAccessTime (4)
             |                             = 2008-7-1,12:49:11.8,+2:0
             |
             + index (264) (ipfixTemplateId)
               +- ipfixTemplateObservationDomainId (1) = 3
               +- ipfixTemplateId (2) = 264
               +- ipfixTemplateSetId (3) = 3
               +- ipfixTemplateAccessTime (4)
                                           = 2008-7-1,12:47:05.3,+2:0

   The table on the second Collector would be analogous to the one shown
   above.

5.3.  The Template Definition Table

   The Template Definition table lists all the Information Elements
   contained in a Template or Options Template.  Therefore, it has the
   same indexes as the corresponding Template table plus the Template
   Id.  Its own index denotes the order of the Information Element
   inside the Template.  Besides the Information Element Id and the
   length of the encoded value, the table contains the enterprise number
   for enterprise-specific Information Elements and flags for each
   Information Element.  The flags indicate if the Information Element
   is used for scoping or as a Flow Key.

   To resume the above example again, the Exporter is configured to
   export the octets received and dropped at the Observation Point since
   the last export of these values.  In addition, it exports the start
   and end time of the Flow relative to the timestamp contained in the
   IPFIX header.  This leads to the following Template Definition table
   on the Exporter:

Top      ToC       Page 10 
    ipfixTemplateDefinitionTable (4)
    |
    +- ipfixTemplateDefinitionEntry (1)
       |
       +- index (5) (ipfixTransportSessionIndex)
          +- index (3) (ipfixTemplateObservationDomainId)
             + index (257) (ipfixTemplateId)
               +- index (1) (ipfixTemplateDefinitionIndex)
               |  +- ipfixTemplateDefinitionIndex (1) = 1
               |  +- ipfixTemplateDefinitionIeId (2) = 158
               |  |                      (flowStartDeltaMicroseconds)
               |  +- ipfixTemplateDefinitionIeLength (3) = 4
               |  +- ipfixTemplateDefinitionEnterprise (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (2) (ipfixTemplateDefinitionIndex)
               |  +- ipfixTemplateDefinitionIndex (1) = 2
               |  +- ipfixTemplateDefinitionIeId (2) = 159
               |  |                      (flowEndDeltaMicroseconds)
               |  +- ipfixTemplateDefinitionIeLength (3) = 4
               |  +- ipfixTemplateDefinitionEnterprise (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (3) (ipfixTemplateDefinitionIndex)
               |  +- ipfixTemplateDefinitionIndex (1) = 3
               |  +- ipfixTemplateDefinitionIeId (2) = 1
               |  |                                 (octetDeltaCount)
               |  +- ipfixTemplateDefinitionIeLength (3) = 8
               |  +- ipfixTemplateDefinitionEnterprise (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (4) (ipfixTemplateDefinitionIndex)
                  +- ipfixTemplateDefinitionIndex (1) = 4
                  +- ipfixTemplateDefinitionIeId (2) = 132
                  |                          (droppedOctetDeltaCount)
                  +- ipfixTemplateDefinitionIeLength (3) = 8
                  +- ipfixTemplateDefinitionEnterprise (4) = 0
                  +- ipfixTemplateDefinitionFlags (5) = 0

   The corresponding table entry on the Collector is the same except
   that it would have another ipfixTransportSessionIndex, e.g., 17 as in
   the previous example.

Top      ToC       Page 11 
5.4.  The Export Table

   On Exporters, the Export table (ipfixExportTable) can be used to
   support features like failover, load-balancing, duplicate export to
   several Collectors, etc.  The table has three indexes that link an
   entry with:

   o  the Metering Process table (ipfixMeteringProcessCacheId, see
      below)

   o  and the Transport Session table (ipfixTransportSessionIndex).

   Those entries with the same ipfixExportIndex and the same
   ipfixMeteringProcessCacheId define a Transport Session group.  The
   member type for each group member describes its functionality.  All
   Transport Sessions referenced in this table MUST have the
   ipfixTransportSessionDeviceMode exporting(1).

   If the Exporter does not use Transport Session grouping, then each
   ipfixExportIndex contains a single ipfixMeteringProcessCacheId, and
   thus a singe Transport Session (ipfixTransportSessionIndex) and this
   session MUST have the member type primary(1).

   For failover, a Transport Session group can contain one Transport
   Session with member type "primary" and several Transport Sessions
   with type secondary(2).  Entries with other member types are not
   allowed for that type of group.  For load-balancing or parallel
   export, all Transport Sessions in the group MUST have the same member
   type, either loadBalancing(4) or parallel(3).

   The algorithms used for failover or load-balancing are out of the
   scope of this document.

   To continue the example, we assume that the Exporter uses the two
   connections shown in the examples above as one primary Transport
   Session protected by a secondary Transport Session.  The Exporter
   then has the following entries in the ipfixExportTable:

Top      ToC       Page 12 
    ipfixExportTable (5)
    |
    +- ipfixExportEntry (1)
       |
       +- index (7) (ipfixExportIndex)
       |  +- index (9) (ipfixMeteringProcessCacheId)
       |     |  +- index (5) (ipfixTransportSessionIndex)
       |        |  +- ipfixExportIndex (1) = 7
       |        |  +- ipfixExportMemberType (2) = 1 (primary)
       |        |
       |        +- index (11) (ipfixTransportSessionIndex)
       |           +- ipfixExportIndex (1) = 7
       |           +- ipfixExportMemberType (2) = 2 (secondary)
       |
       +- index (8) (ipfixExportIndex)
          +- index (9) (ipfixMeteringProcessCacheId)
             +- index (5) (ipfixTransportSessionIndex)
             |  +- ipfixExportIndex (1) = 8
             |  +- ipfixExportMemberType (2) = 2 (secondary)
             +- index (11) (ipfixTransportSessionIndex)
                +- ipfixExportIndex (1) = 8
                +- ipfixExportMemberType (2) = 1 (primary)

   The example shows that the Exporter uses the Metering Process Cache
   9, explained below, to export IPFIX Data Records for the Transport
   Sessions 5 and 11.  The Templates 257 and 264 defined above are
   exported within Transport Session 5, and the Templates 273 and 289
   are exported within Transport Session 11.  If we assume that
   Templates 257 and 264 are identical, then the Collector that receives
   Transport Session 11 is a backup for the Collector of Transport
   Session 5.

5.5.  The Metering Process Table

   The Metering Process, as defined in [RFC5101], consists of a set of
   functions.  Maintaining the Flow Records is one of them.  This
   function is responsible for passing the Flow Records to the Exporting
   Process and also for detecting Flow expiration.  The Flow Records
   that are maintained by the Metering Process can be grouped by the
   Observation Points at which they are observed.  The instance that
   maintains such a group of Flow Records is a kind of cache.  For this
   reason, the Metering Process table (ipfixMeteringProcessTable) is
   indexed by cache Ids (ipfixMeteringProcessCacheId).  Each cache can
   be maintained by a separate instance of the Metering Process.  To
   specify the Observation Point(s) where the Flow Records are gathered,
   the ipfixMeteringProcessObservationPointGroupRef may contain an
   ipfixObservationPointGroupId from the Observation Point table
   (ipfixObservationPointTable) described in the next section.  If an

Top      ToC       Page 13 
   Observation Point is not specified for the Flow Records, the
   ipfixMeteringProcessObservationPointGroupRef MUST be zero(0).  The
   timeouts (ipfixMeteringProcessCacheActiveTimeout and
   ipfixMeteringProcessCacheInactiveTimeout) specify when Flows are
   expired.

    ipfixMeteringProcessTable (6)
    |
    +- ipfixMeteringProcessEntry (1)
       |
       +- index (9) (ipfixMeteringProcessCacheId)
          +- ipfixMeteringProcessCacheId (1) = 9
          +- ipfixMeteringProcessObservationPointGroupRef (2) = 17
          +- ipfixMeteringProcessCacheActiveTimeout (3) = 100
          +- ipfixMeteringProcessCacheInactiveTimeout (4) = 100

5.6.  The Observation Point Table

   The Observation Point table (ipfixObservationPointTable) groups
   Observation Points with the ipfixObservationPointGroupId.  Each entry
   contains the Observation Domain Id in which the Observation Point is
   located and a reference to the ENTITY MIB module [RFC4133] or the IF
   MIB module [RFC2863].  The objects in the ENTITY MIB module
   referenced by ipfixObservationPointPhysicalEntity or IF MIB module
   referenced by ipfixObservationPointPhysicalInterface denote the
   Observation Point.  If no such index can be given in those modules,
   the references MUST be 0.  If a reference is given in both object
   ipfixObservationPointPhysicalEntity and
   ipfixObservationPointPhysicalInterface, then both MUST point to the
   same physical interface.  In addition, a direction can be given to
   render more specifically which Flow to monitor.

Top      ToC       Page 14 
    ipfixObservationPointTable (7)
    |
    +- ipfixObservationPointEntry (1)
       |
       +- index (17) (ipfixObservationPointGroupId)
          +- index (1) (ipfixObservationPointIndex)
          |  +- ipfixObservationPointGroupId (1) = 17
          |  +- ipfixObservationPointIndex (2) = 1
          |  +- ipfixObservationPointObservationDomainId (3) = 3
          |  +- ipfixObservationPointPhysicalEntity (4) = 6
          |  +- ipfixObservationPointPhysicalInterface(5) = 0
          |  +- ipfixObservationPointPhysicalEntityDirection (6)
                                                             = 3 (both)
          |
          +- index (2) (ipfixObservationPointIndex)
             +- ipfixObservationPointGroupId (1) = 17
             +- ipfixObservationPointIndex (2) = 2
             +- ipfixObservationPointObservationDomainId (3) = 3
             +- ipfixObservationPointPhysicalEntity (4) = 0
             +- ipfixObservationPointPhysicalInterface (5) = 0
             +- ipfixObservationPointPhysicalEntityDirection (6)
                                                           = 1 (ingress)

5.7.  The Selection Process Table

   This table supports the usage of Filtering and Sampling functions, as
   described in [RFC5470].  It contains lists of functions per Metering
   Process cache (ipfixMeteringProcessCacheId).  The selection process
   index ipfixSelectionProcessIndex forms groups of selection methods
   that are applied to an observed packet stream.  The selection process
   selector index (ipfixSelectionProcessSelectorIndex) indicates the
   order in which the functions are applied to the packets observed at
   the Observation Points associated with the Metering Process cache.
   The selection methods are applied in increasing order, i.e.,
   selection methods with a lower ipfixSelectionProcessSelectorIndex are
   applied first.  The functions are referred by object identifiers
   pointing to the function with its parameters.  If the selection
   method does not use parameters, then it MUST point to the root of the
   function subtree (see also Section 6).  If the function uses
   parameters, then it MUST point to an entry in the parameter table of
   the selection method.  If no Filtering or Sampling function is used
   for a Metering Process, then an entry for the Metering Process SHOULD
   be created pointing to the Select All function (ipfixFuncSelectAll).

Top      ToC       Page 15 
5.8.  The Statistical Tables

   For the ipfixTransportSessionTable, the ipfixTemplateTable, the
   ipfixMeteringProcessTable, and the ipfixSelectionProcessTable
   statistical tables are defined that augment those tables.  All the
   statistical tables contain a discontinuity object that holds a
   timestamp that denotes the time when a discontinuity event occurred
   to notify the management system that the counters contained in those
   tables might not be continuous anymore.

5.8.1.  The Transport Session Statistical Table

   The Transport Session Statistical table
   (ipfixTransportSessionStatsTable) augments the
   ipfixTransportSessionTable with statistical values.  It contains the
   rate (in bytes per second) with which it receives or sends out IPFIX
   Messages, the number of bytes, packets, messages, Records, Templates
   and Options Templates received or sent and the number of messages
   that were discarded.

5.8.2.  The Template Statistical Table

   This table contains a statistical value for each Template.  It
   augments the Template table (ipfixTemplateTable) and specifies the
   number of Data Records exported or collected for the Template.

5.8.3.  The Metering Process Statistical Table

   This table augments the Metering Process table
   (ipfixMeteringProcessTable).  It contains the statistical values for
   the exported Data Records and the number of unused cache entries.

5.8.4.  The Selection Process Statistical Table

   This table augments the Selection Process table
   (ipfixSelectionProcessTable) and introduces two generic statistical
   values, the number of packets observed and the number of packets
   dropped by the selection method.

6.  Structure of the IPFIX SELECTOR MIB

   The IPFIX SELECTOR MIB module defined in this section provides the
   standard Filtering and Sampling functions that can be referenced in
   the ipfixSelectionProcessTable.  The subtree ipfixSelectorFunctions
   is a placeholder where all standard Filtering and Sampling functions
   should be located.  It currently contains the Select All function
   (ipfixFuncSelectAll).  The IPFIX SELECTOR MIB module is maintained by
   IANA and can be extended through Expert Review [RFC5226], i.e.,

Top      ToC       Page 16 
   review by one of a group of experts designated by an IETF Area
   Director.  The group of experts MUST check the requested MIB objects
   for completeness and accuracy of the description.  Requests for MIB
   objects that duplicate the functionality of existing objects SHOULD
   be declined.  The smallest available OID SHOULD be assigned to a new
   MIB objects.  The specification of new MIB objects SHOULD follow the
   structure specified in the next Section and MUST be published using a
   well-established and persistent publication medium.  The experts will
   initially be drawn from the Working Group Chairs and document editors
   of the IPFIX and PSAMP Working Groups.

6.1.  The Selector Functions

   The following figure shows what the MIB tree usually should look
   like.  It already contains the ipfixFuncSelectAll.  The subtree in
   ipfixFuncF2 gives the basic structure that all selection methods
   SHOULD follow.

    ipfixSelectorFunctions
    |
    +- ipfixFuncSelectAll
    |  |
    |  +- ipfixFuncSelectAllAvail (is the function available?)
    |
    +- ipfixFuncF2
    |  |
    |  +- ipfixFuncF2Avail (is the function F2 available?)
    |  |
    |  +- ipfixFuncF2Parameters (a table with parameters)
    ...
    |
    +- ipfixFunFn...

   The selection method SHOULD be designed as a MIB subtree introduced
   by an object with the name ipfixFunc appended by a function name.
   The objects in this subtree SHOULD be prefixed by this name.  If the
   function is named Fx, then we would start a subtree with an OID named
   ipfixFuncFx.  This subtree should contain an object ipfixFuncFxAvail
   that has the type TruthValue.  If a selection method takes
   parameters, the MIB should contain a table named
   ipfixFuncFxParameters, which should contain all the parameters that
   the selection method specifies.  An entry in this table will be
   referenced by the IPFIX MIB module if the selection method with the
   parameters is used.

Top      ToC       Page 17 
   To illustrate the structure defined above, the following contains an
   example of a function MyFunc that holds three integer parameters
   Param1, Param2, and Param3.  In the example, there are currently two
   instances of the parameters set defined with indexes 1 and 4.

    ipfixSelectorFunctions (1)
    |
    +- ipfixFuncMyFunc (?)
       |
       +- ipfixFuncMyFuncAvail (1) = true
       +- ipfixFuncMyFuncParameters (2)
          |
          +- ipfixFuncMyFuncParametersEntry (1)
             |
             +- index (1) (ipfixFuncMyFuncParametersIndex)
             |  +- ipfixFuncMyFuncParam1 (1) = 47
             |  +- ipfixFuncMyFuncParam2 (2) = -128
             |  +- ipficFuncMyFuncParam3 (3) = 19
             |
             +- index(4) (ipfixFuncMyFuncParametersIndex)
                +- ipfixFuncMyFuncParam1 (1) = 19
                +- ipfixFuncMyFuncParam2 (2) = -1
                +- ipficFuncMyFuncParam3 (3) = 728

   If the function defined above is referenced in the IPFIX MIB module,
   the ipfixSelectionProcessTable would look as follows:

    ipfixSelectionProcessTable (8)
    |
    +- ipfixSelectionProcessEntry (1)
       |
       +- index (9) (ipfixMeteringProcessCacheId)
          +- index (1) (ipfixSelectionProcessIndex)
             +- index (1) (ipfixSelectionProcessSelectorIndex)
             |  +- ipfixSelectionProcessSelectorFunction (3)
             |                          = ipfixSelectorFunctions.?.2.1.4
             +- index (2) (ipfixSelectionProcessSelectorIndex)
                +- ipfixSelectionProcessSelectorFunction (3)
                                        = ipfixSelectorFunctions.?.2.1.1

   This means that for the ipfixMeteringProcessCacheId(9), a Selection
   Process with index 1 is created that applies two times the same
   function but with different parameter sets.  First, the function
   MyFunc is applied with the parameters of the set with index 4 and the
   with the parameters of the set with index 1.

Top      ToC       Page 18 
7.  Relationship to Other MIB Modules

   Besides the usual imports from the SNMP Standards [RFC2578],
   [RFC2579], and [RFC2580], the IPFIX MIB module references the ENTITY
   MIB module [RFC4133] and the IF MIB module [RFC2863].

7.1.  Relationship to the ENTITY MIB and IF MIB

   The Observation Point table (ipfixObservationPointTable) contains a
   reference to the ENTITY MIB module[RFC4133]
   (ipfixObservationPointPhysicalEntity) or the IF MIB module [RFC2863]
   (ipfixObservationPointPhysicalInterface).  If the implementors of the
   IPFIX MIB module want to specify the physical entity where Flows are
   observed, then they SHOULD also implement the ENTITY MIB and/or the
   IF MIB module.  The implementation of the ENTITY MIB and/or IF MIB
   module is OPTIONAL.  If one of them is not implemented, then all
   values of the respective column ipfixObservationPointPhysicalEntity
   or ipfixObservationPointPhysicalInterface in the Observation Point
   table are zero and the values of the
   ipfixObservationPointPhysicalEntityDirection columns are unknown(0),
   if none of them are defined.

7.2.  MIB Modules Required for IMPORTS

   The IPFIX MIB module requires the modules SNMPv2-SMI [RFC2578],
   SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580].  Further on, it
   imports the textual conventions InetAddressType and InetAddress from
   the INET ADDRESS MIB module [RFC4001].

   The IPFIX SELECTOR MIB module also requires the modules SNMPv2-SMI
   [RFC2578], SNMPv2-TC [RFC2579], and SNMPv2-CONF [RFC2580].



(page 18 continued on part 2)

Next RFC Part