Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6615

Definitions of Managed Objects for IP Flow Information Export

Pages: 65
Proposed Standard
Obsoletes:  5815
Part 1 of 3 – Pages 1 to 19
None   None   Next

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


     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 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/rfc6615. Copyright Notice Copyright (c) 2012 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   ToC   RFC6615 - 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 ................................13 5.6. The Observation Point Table ...............................14 5.7. The Selection Process Table ...............................15 5.8. The Statistical Tables ....................................16 5.8.1. The Transport Session Statistical Table ............16 5.8.2. The Template Statistical Table .....................16 5.8.3. The Metering Process Statistical Table .............16 5.8.4. The Selection Process Statistical Table ............16 6. Structure of the IPFIX SELECTOR MIB ............................16 6.1. The Selector Functions ....................................17 7. Relationship to Other MIB Modules ..............................19 7.1. Relationship to the ENTITY MIB and Interfaces MIB .........19 7.2. MIB Modules Required for IMPORTS ..........................19 8. MIB Definitions ................................................20 8.1. IPFIX MIB Definition ......................................20 8.2. IPFIX SELECTOR MIB Definition .............................56 9. Security Considerations ........................................60 10. IANA Considerations ...........................................61 11. Acknowledgments ...............................................62 12. References ....................................................62 12.1. Normative References .....................................62 12.2. Informative References ...................................63
Top   ToC   RFC6615 - Page 3

1. Introduction

This document defines two MIB modules for monitoring IP Flow Information eXport (IPFIX) Devices, including Exporters and Collectors. While 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", "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 are performed according to the IPFIX architecture defined in [RFC5470]. The monitored configuration parameters of the export and collection of Flow Templates and Data Records are modeled according to [RFC5101]. Packet selection methods that may be optionally used by the IPFIX Metering Process are not considered in this MIB document. 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   RFC6615 - 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 basic terms such as 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 IPFIX 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 the 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   RFC6615 - Page 5
   well as the source and destination port.  For the Stream Control
   Transmission Protocol (SCTP), the table contains
   ipfixTransportSessionSctpAssocId, which is the index for the SCTP
   association in the SCTP MIB module [RFC3873].  The mode of operation
   of the device, i.e., whether the Transport Session is used for
   collecting or exporting, is given in the
   ipfixTransportSessionDeviceMode object.  Further on, the table
   contains the configured refresh parameters for Templates and Options
   Templates that are used across unreliable connections such as UDP.
   Finally, the IPFIX version that is exported or collected by this
   Transport Session and a status of the Transport Session are given in
   the table.

   To illustrate the use of this table, 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   RFC6615 - 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
       |  +- ipfixTransportSessionOptionsTemplateRefreshTimeout (12) = 0
       |  +- ipfixTransportSessionTemplateRefreshPacket (13) = 0
       |  +- ipfixTransportSessionOptionsTemplateRefreshPacket (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
          +- ipfixTransportSessionOptionsTemplateRefreshTimeout (12)
          |                                                     = 100
          +- ipfixTransportSessionTemplateRefreshPacket (13) = 10
          +- ipfixTransportSessionOptionsTemplateRefreshPacket (14) = 10
          +- ipfixTransportSessionIpfixVersion (15) = 10
          +- ipfixTransportSessionStatus (16) = 2 (active)

   The values in parentheses are the OID numbers.  The Collectors would
   then have the same entry, except that the index would most likely
   differ and the ipfixTransportSessionDeviceMode value would be
   collecting(2).
Top   ToC   RFC6615 - 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 Observation Domain and per Transport Session. Note that the Transport Session also gives the device mode, i.e., Exporter or Collector. Thus, the table is indexed by o the Transport Session Index (ipfixTransportSessionIndex) and o 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, which defines the Template and Options Template:
Top   ToC   RFC6615 - 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   RFC6615 - 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 whether 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   RFC6615 - 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
               |  +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (2) (ipfixTemplateDefinitionIndex)
               |  +- ipfixTemplateDefinitionIndex (1) = 2
               |  +- ipfixTemplateDefinitionIeId (2) = 159
               |  |                      (flowEndDeltaMicroseconds)
               |  +- ipfixTemplateDefinitionIeLength (3) = 4
               |  +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (3) (ipfixTemplateDefinitionIndex)
               |  +- ipfixTemplateDefinitionIndex (1) = 3
               |  +- ipfixTemplateDefinitionIeId (2) = 1
               |  |                                 (octetDeltaCount)
               |  +- ipfixTemplateDefinitionIeLength (3) = 8
               |  +- ipfixTemplateDefinitionEnterpriseNumber (4) = 0
               |  +- ipfixTemplateDefinitionFlags (5) = 0
               |
               +- index (4) (ipfixTemplateDefinitionIndex)
                  +- ipfixTemplateDefinitionIndex (1) = 4
                  +- ipfixTemplateDefinitionIeId (2) = 132
                  |                          (droppedOctetDeltaCount)
                  +- ipfixTemplateDefinitionIeLength (3) = 8
                  +- ipfixTemplateDefinitionEnterpriseNumber (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   RFC6615 - 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) and o 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 a ipfixTransportSessionDeviceMode value of exporting(1). If the Exporter does not use Transport Session grouping, then each ipfixExportIndex contains a single ipfixMeteringProcessCacheId, and thus a single Transport Session (ipfixTransportSessionIndex); this session MUST have a member type value of primary(1). For failover, a Transport Session group can contain one Transport Session with member type primary(1) 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   RFC6615 - 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
   (index (9)), explained below, to export IPFIX Data Records for
   Transport Sessions 5 and 11.  Templates 257 and 264 defined above are
   exported within Transport Session 5 as primary, while the secondary
   Transport Session is 11.  Templates 273 and 289 are exported within
   Transport Session 11 as primary, while the secondary Transport
   Session is 5.

   Here are the steps required by a manager in order to understand what
   the backups are (if any) for Template Records exported from a
   specific Exporter to a specific Collector:

   1.  Look up the Collector IP address in the
       ipfixTransportSessionDestinationAddress object (in the
       ipfixTransportSessionTable).

   2.  From the same row, double-check the Exporter IP address in the
       ipfixTransportSessionSourceAddress object.

   3.  From the same row, write down the ipfixTransportSessionIndex
       value.
Top   ToC   RFC6615 - Page 13
   4.  Use that ipfixTransportSessionIndex value in the
       ipfixTemplateTable and look up the pairs of
       (ipfixTemplateObservationDomainId, ipfixTemplateId).  From there,
       the manager deduces the Template Record(s) (ipfixTemplateId),
       exported from the Observation Domain(s)
       (ipfixTemplateObservationDomainId) on the tracked Exporter
       (ipfixTransportSessionSourceAddress) to the tracked Collector
       (ipfixTransportSessionDestinationAddress).

   5.  Reusing the same ipfixTransportSessionIndex in the
       ipfixExportTable, look in the table for a value of
       ipfixExportMemberType that equals "primary".  Note that there
       could be multiple entries for which the ipfixExportMemberType
       equals "primary" in the ipfixExportTable, so multiple iterations
       might be required until the correct value of
       ipfixTransportSessionIndex is found.

   6.  From the same row, write down the ipfixExportIndex value.

   7.  In the ipfixExportTable, under the same three index values
       (ipfixExportIndex, ipfixMeteringProcessCacheId, and
       ipfixTransportSessionIndex), look up the entries for which
       ipfixExportMemberType is different than "primary".  Write down
       the associated ipfixTransportSessionIndex value.

   8.  From the ipfixTransportSessionTable, look up the Transport
       Session details for this ipfixTransportSessionIndex value -- for
       example, the secondary Collector IP address and port
       (ipfixTransportSessionDestinationAddress and
       ipfixTransportSessionSourcePort).

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), which is described in the next subsection. If an Observation Point is not specified for the Flow
Top   ToC   RFC6615 - Page 14
   Records, the ipfixMeteringProcessObservationPointGroupRef MUST be
   zero(0).  The timeouts (ipfixMeteringProcessCacheActiveTimeout and
   ipfixMeteringProcessCacheIdleTimeout) specify when Flows are expired.

    ipfixMeteringProcessTable (6)
    |
    +- ipfixMeteringProcessEntry (1)
       |
       +- index (9) (ipfixMeteringProcessCacheId)
          +- ipfixMeteringProcessCacheId (1) = 9
          +- ipfixMeteringProcessObservationPointGroupRef (2) = 17
          +- ipfixMeteringProcessCacheActiveTimeout (3) = 100
          +- ipfixMeteringProcessCacheIdleTimeout (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 Interfaces MIB module [RFC2863]. The objects in the ENTITY MIB module referenced by ipfixObservationPointPhysicalEntity, or the objects in the Interfaces MIB module referenced by ipfixObservationPointPhysicalInterface, denote the Observation Point. At least one reference for the objects ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface MUST exist for a valid Observation Point entry. If a reference to the Observation Point is given in both object ipfixObservationPointPhysicalEntity and ipfixObservationPointPhysicalInterface, then both MUST point to the same physical interface. However, if one of two references (ipfixObservationPointPhysicalEntity or ipfixObservationPointPhysicalInterface) cannot be given, its reference MUST be 0. In addition, a direction can be given to render more specifically which Flow to monitor.
Top   ToC   RFC6615 - Page 15
    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 referenced by object identifiers pointing to each 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 that points to the Select All function (ipfixFuncSelectAll).
Top   ToC   RFC6615 - Page 16

5.8. The Statistical Tables

Statistical tables that augment the ipfixTransportSessionTable, ipfixTemplateTable, ipfixMeteringProcessTable, and ipfixSelectionProcessTable have been defined. All the statistical tables contain a discontinuity object that holds a timestamp denoting the time when a discontinuity event occurred, in order 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) at 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. All standard Filtering and Sampling functions MUST be registered in the subtree under object ipfixSelectorFunctions (iso.org.dod.internet.mgmt.mib-2. ipfixSelectorMIB.ipfixSelectorObjects.ipfixSelectorFunctions, or 1.3.6.1.2.1.194.1.1). The top-level OIDs in the subtree under object
Top   ToC   RFC6615 - Page 17
   ipfixSelectorFunctions MUST be registered in a sub-registry
   maintained by IANA at http://www.iana.org/assignments/smi-numbers.
   The first entry in this subtree is the Select All function
   (ipfixFuncSelectAll), defined in this document as
   {ipfixSelectorFunctions 1}.

   New Selector Functions MUST be registered at IANA and are subject to
   Expert Review [RFC5226], i.e., 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 new MIB objects.  The
   specification of new MIB objects SHOULD follow the structure
   specified in Section 6.1 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 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) ... | +- ipfixFuncFn... 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
Top   ToC   RFC6615 - Page 18
   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.

   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 parameter sets, 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
             |  +- ipfixFuncMyFuncParam3 (3) = 19
             |
             +- index(4) (ipfixFuncMyFuncParametersIndex)
                +- ipfixFuncMyFuncParam1 (1) = 19
                +- ipfixFuncMyFuncParam2 (2) = -1
                +- ipfixFuncMyFuncParam3 (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
Top   ToC   RFC6615 - Page 19
   This means that for the ipfixMeteringProcessCacheId(9), a Selection
   Process with index 1 is created that applies the same function two
   times but with different parameter sets.  First, the function MyFunc
   is applied with the parameters of the set with index 4, and then with
   the parameters of the set with index 1.

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 Interfaces MIB module [RFC2863].

7.1. Relationship to the ENTITY MIB and Interfaces MIB

The Observation Point table (ipfixObservationPointTable) contains a reference to the ENTITY MIB module [RFC4133] (ipfixObservationPointPhysicalEntity) and a reference to the Interfaces MIB module [RFC2863] (ipfixObservationPointPhysicalInterface). If the implementers 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 Interfaces MIB module. The implementation of the ENTITY MIB and/or the Interfaces 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].


(next page on part 2)

Next Section