One document matched: draft-ietf-ipfix-mib-variable-export-10.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<!--
One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY RFC2856 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2856.xml">
<!ENTITY RFC2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY RFC2982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2982.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3414.xml">
<!ENTITY RFC3415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3415.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC4022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4022.xml">
<!ENTITY RFC4293 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC4750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4750.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5470.xml">
<!ENTITY RFC5476 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5476.xml">
<!ENTITY RFC5591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5591.xml">
<!ENTITY RFC5592 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5592.xml">
<!ENTITY RFC6235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6235.xml">
<!ENTITY RFC6313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6313.xml">
<!ENTITY RFC6353 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6353.xml">
<!ENTITY RFC6526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6526.xml">
<!ENTITY RFC7011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7012.xml">
]>
<!-- used by XSLT processors -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!--
For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html.
-->
<!--
Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32)
-->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="3"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e., [RFC2119] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!--
Control vertical white space (using these PIs as follows is recommended by the RFC Editor)
-->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!--
category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)"
-->
<rfc category="std"
docName="draft-ietf-ipfix-mib-variable-export-10"
ipr="trust200902">
<!--
***************** AUTHOR NOTES ******************
XML RENDERING NOTES:
- There is a bug in xml2rfc where the bit numbers at the top of the artwork need to be oddly aligned to render properly.
-->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="Exporting MIB Variables with IPFIX">
Exporting MIB Variables using the IPFIX Protocol
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Paul Aitken" initials="P." surname="Aitken" role="editor">
<organization>Brocade Communications Systems, Inc.</organization>
<address>
<postal>
<street>19a Canning Street, Level 3</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH3 8EG</code>
<country>United Kingdom</country>
</postal>
<phone>+44 203 005 0731</phone>
<email>paitken@brocade.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>Diegem</city>
<region></region>
<code>1813</code>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Srikar B S" initials="S." surname="B S">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Mail Stop BGL13/3/, SEZ Unit, Cessna Business Park, Kadubeesanahalli</street>
<street>Village Varthur Hobli, Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region></region>
<code>KARNATAKA 560 103</code>
<country>IN</country>
</postal>
<phone>+91 80 4426 3264</phone>
<email>srikar@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Colin McDowall" initials="C." surname="McDowall">
<organization>Brocade Communications Systems, Inc.</organization>
<address>
<postal>
<street>19a Canning Street, Level 3</street>
<city>Edinburgh</city>
<region>Scotland</region>
<code>EH3 8EG</code>
<country>United Kingdom</country>
</postal>
<phone>+44 203 005 0687</phone>
<email>cmcdowal@brocade.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Juergen Schoenwaelder" initials="J." surname="Schoenwaelder">
<organization>Jacobs University Bremen</organization>
<address>
<postal>
<street>Campus Ring 1</street>
<city>Bremen</city>
<region></region>
<code>28725</code>
<country>Germany</country>
</postal>
<phone>+49 421 200-3587</phone>
<email>j.schoenwaelder@jacobs-university.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year.
-->
<date year="2015"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force (IETF)</workgroup>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<keyword>IPFIX</keyword>
<keyword>MIB</keyword>
<keyword>SNMP</keyword>
<abstract>
<t>
This document specifies a way to complement IPFIX Data Records
with Management Information Base (MIB) objects, avoiding the need to define
new IPFIX Information Elements for existing Management
Information Base objects that are already fully specified.
</t>
<t>
An IPFIX Options Template and method are specified, which are used to
export the extra information required to fully describe
Simple Network Management Protocol (SNMP) MIB objects in IPFIX.
</t>
</abstract>
</front>
<middle>
<!-- PJ: this is section 2: -->
<section anchor="sectionIntroduction" title="Introduction">
<t>
There is growing interest in using IPFIX as a push mechanism for
exporting management information. Using a push protocol such as
IPFIX instead of a polling protocol like SNMP is especially
interesting in situations where large chunks of repetitive data
need to be exported periodically.
</t>
<t>
While initially targeted at different problems, there is a large
parallel between the information transported via IPFIX and SNMP.
Furthermore, certain Management Information Base (MIB) objects
are highly relevant to flows as they are understood today. For
example, in the IPFIX information model <xref target="IANA-IPFIX"
/>, Information Elements coming from the SNMP world have already
been specified, e.g., ingressInterface and egressInterface both
refer to the ifIndex defined in <xref target="RFC2863"/>.
</t>
<t>
In particular the Management Information Base was designed as a separate
system of definitions which opens up the possibility of exporting Objects
defined via the MIB over other protocols.
</t>
<t>
Rather than mapping existing MIB objects to IPFIX Information
Elements on a case by case basis, it would be advantageous to
enable the export of any existing or future MIB objects as part
of an IPFIX Data Record. This way, the duplication of data
models <xref target="RFC3444"/>, both as SMIv2 MIB objects and
IPFIX Information Elements, out of the same information model
<xref target="RFC3444"/> would be avoided.
</t>
<t>
Therefore the primary goals of this document are:
<list style="symbols">
<t>to specify a way to complement IPFIX Data Records with Management Information Base (MIB) objects;</t>
<t>to avoid the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified;</t>
<t>to allow the correlation of SNMP and IPFIX sourced data by exporting them together;</t>
<t>to allow SNMP push data from SNMP-only devices to be more easily integrated into IPFIX based collection infrastructures.</t>
</list>
</t>
</section>
<!-- PJ: this is section 3: -->
<section anchor="sectionMotivation" title="Motivation">
<t>
The intended scope of this work is the addition of MIB
variable(s) to IPFIX Information Elements in Data Records, in
order to complement the Records with useful and already
standardized information. Special consideration is given to the
case of an existing Template Record which needs to be augmented
with some MIB variables whose index is already present in the
Template Record as an IPFIX Information Element. For example
a 7-tuple Record containing the ingressInterface Information Element,
which needs to be augmented by interface counters
<xref target="RFC2863"/> which are indexed by the respective
ingressInterface values which are already contained in the Data Records.
See <xref target="sectionTerminology"/> for terminology definitions.
</t>
<t>
Many Data Records contain the ingressInterface and/or the
egressInterface Information Elements. These Information Elements
carry an ifIndex value, a MIB object defined in
<xref target="RFC2863"/>. In order to retrieve additional
information about the identified interface, a Collector could
simply poll relevant objects from the device running the
Exporter via SNMP. However, that approach has several problems:
<list style="symbols">
<t>
It requires implementing a mediation function between two
data models, i.e., MIB objects and IPFIX Information
Elements.
</t>
<t>
Confirming the validity of simple mappings (e.g., ifIndex to
ifName) requires either checking on a regular basis that the
Exporter's network management system did not reload, or
imposing ifIndex persistence across an Exporter's reload.
</t>
<t>
Synchronization problems occur since counters carried in
Data Records and counters carried in SNMP messages are
retrieved from the Exporter at different points in time and
thus cannot be correlated. In the best case, assuming very
tight integration of an IPFIX Collector with an SNMP
polling engine, SNMP data is retrieved shortly after Data
Records have been received, which implies a delay of the sum of the
active or inactive timeouts (if not null) plus the time to
export the Data Record to the Collector. If, however, the
SNMP data is retrieved by a generic Network Management Station
(NMS) polling interface statistics, then the time lag between
IPFIX counters and SNMP counters can be significantly higher.
See <xref target="RFC5470"/> section 5.1.1. "Flow Expiration" for details of
active and inactive timeouts.
</t>
</list>
</t>
<t>
This document does not specify how to carry SNMP notifications in IPFIX,
even if the specifications in this document could potentially allow this.
</t>
<t>Since IPFIX is a push mechanism,
initiated from the Exporter with no acknowledgment method, this
specification does not provide the ability to execute
configuration changes.
</t>
<t>
The Distributed Management Expression MIB
<xref target="RFC2982"/>, which is a mechanism to create new MIB
variables based on the content of existing ones, could also be
advantageous in the context of this specification. Indeed, newly
created MIB objects (for example, the link utilization MIB variable),
created with the Distributed Management Expression MIB
<xref target="RFC2982"/> could nicely complement Data Records.
</t>
<t>
Another advantage of exporting MIB objects via IPFIX is that IPFIX
would benefit from an extended series of types to be exported. The
simple and application-wide data types specified in SMIv2
<xref target="RFC2578"/>, along with new Textual Conventions, can be
exported within IPFIX and then decoded in the Collector.
However, since a Textual Convention can contain almost any name,
this document does not extend the existing
informationElementDataType registry <xref target="IANA-IPFIX"/>.
</t>
<t>
The overall architectural model is depicted in
<xref target="figure_arch"/>. The IPFIX Exporter accesses the
device's instrumentation, which follows the specifications
contained in MIB modules. Other management interfaces such as
NETCONF or the device's Command Line Interface (CLI) may provide
access to the same instrumentation.
</t>
<figure align="center" anchor="figure_arch"
title="Architectural Model">
<artwork align="center">
+------+ +-------+ +.........+ +.....+
| SNMP | | IPFIX | : NETCONF : : CLI :
+------+ +-------+ +.........+ +.....+
| | | |
+--------------------------------------------+
| Instrumentation (specified in MIB modules) |
+--------------------------------------------+
</artwork>
</figure>
</section>
<!-- PJ: this is section 4: -->
<section anchor="sectionTerminology" title="Terminology">
<t>
IPFIX-specific terminology (Information Element, Template,
Template Record, Options Template Record, Template Set,
Collector, Exporter, Data Record, etc.) used in this document is
defined in Section 2 of <xref target="RFC7011"/>. As in
<xref target="RFC7011"/>, these IPFIX-specific terms have the
first letter of a word capitalized.
</t>
<t>
This document prefers the more generic term "Data Record"
(as opposed to "Flow Record") in relation to the export of MIB objects.
</t>
<t>Object Identifier (MIB OID)
<list hangIndent="5" style="empty">
<t>
An Object Identifier value is an ordered list of non-negative
numbers. For the SMIv2, each number in the list is referred to as a
sub-identifier. There are at most 128 sub-identifiers in a value, and
each sub-identifier has a maximum value of 2^32 - 1 (4294967295
decimal). See <xref target="RFC2578"/> Section 3.5.
</t>
</list>
</t>
<t>MIB Object Identifier Information Element
<list hangIndent="5" style="empty">
<t>
An IPFIX Information Element ("mibObjectIdentifier")
which denotes that a MIB Object Identifier (MIB OID) is exported in the
(Options) Data Record. See <xref target="mibObjectIdentifierIE"/>.
</t>
</list>
</t>
<t>SMIv2 Terminology
<list hangIndent="5" style="empty">
<t>
The key words "MIB Module", "MIB Object", "INDEX", "AUGMENTS",
"textual convention", "columnar object", "conceptual row", and "conceptual table"
in this document are to be interpreted as described in SMIv2 <xref target="RFC2578"/>
</t>
</list>
</t>
<t>SMIv2 SYNTAX
<list hangIndent="5" style="empty">
<t>
The SYNTAX key words "INTEGER", "Integer32", "OCTET STRING", "OBJECT IDENTIFIER", "BITS construct", "IpAddress", "Counter32",
"Gauge32", "TimeTicks", "Opaque", "Counter64", "Unsigned32", "SEQUENCE", and "SEQUENCE OF" in this document
are to be interpreted as described in SMIv2 <xref target="RFC2578"/>.
</t>
</list>
</t>
<t>SNMP Context Terminology
<list hangIndent="5" style="empty">
<t>
The key words "snmpEngineID", "contextEngineID", and "contextName"
in this document are to be interpreted as described in <xref target="RFC3411"/>
</t>
</list>
</t>
<t>mibObjectValue Information Elements
<list hangIndent="5" style="empty">
<t>Refers to any and all of the mibObjectValue Information Elements generically.
Any restriction or requirement in this document that refers to mibObjectValue
applies to the following Information Elements
defined in <xref target="sectionIANANewElementsValues"/>:
mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueIPAddress, mibObjectValueBITS,
mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned,
mibObjectValueTable, and mibObjectValueRow.
</t>
</list>
</t>
<t>IE
<list hangIndent="5" style="empty">
<t>
Used as a shorthand for "Information Element" <xref target="RFC7011"/> in the figures.
</t>
</list>
</t>
<!-- ADD MORE TERMINOLOGY LIKE THIS
<t>Term goes here!
<list hangIndent="5" style="empty">
<t>Defintion goes here!</t>
</list>
</t>
-->
<t>
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 <xref target="RFC2119"/>.
</t>
</section> <!-- Terminology -->
<!-- CM: this is section 4: -->
<section anchor="sectionHighLevelOverview" title="High Level Solution Overview">
<t>
This document specifies a method for creating IPFIX Options Templates
that are used to export the extra data required
to describe MIB variables (see <xref target="sectionMIBFieldOptionArchitecture"/>).
</t><t>
This allows IPFIX Templates to contain any
combination of fields defined by traditional IPFIX Information
Element(s) and/or MIB Object Identifier(s). The MIB Object Identifiers
can reference either non-columnar or columnar MIB object(s).
Enterprise-specific MIB Object Identifiers are also supported.
</t>
<t>
This document also defines two standard IPFIX Options Templates (see <xref target="sectionMIBFieldOptionFormat"/>) that are used
as part of the mechanism to export MIB object meta data:
<list style="symbols">
<t>MIB Field Options Template (<xref target="requiredMinimum"/>)</t>
<t>MIB Type Options Template (<xref target="requiredMinimumType"/>)</t>
</list>
</t>
<t>
This document defines three classes of new IPFIX Information Elements. These
are used to export values from the MIB, export required Object Identifier information,
and optionally export type data from a MIB Module:
<list style="symbols">
<t>MIB Object Value Information Elements (<xref target="sectionIANANewElementsValues"/>)</t>
<t>MIB Field Options Information Elements (<xref target="sectionIANANewElementsMIBFieldOption"/>)</t>
<t>MIB Type Information Information Elements (<xref target="sectionIANANewElementsMIBTypeOption"/>)</t>
</list>
</t>
<t>
Additionally, this document defines two new IPFIX semantics which are required for the new Information Elements:
<list style="symbols">
<t>snmpCounter (<xref target="snmpCounter"/>)</t>
<t>snmpGauge (<xref target="snmpGauge"/>)</t>
</list>
</t>
<t>
Two common types defined in the SMIv2 are conceptual rows and
conceptual tables. It is desirable that exporting a complete
or partial conceptual row is simple and efficient. This is accomplished
by using IPFIX Structured Data <xref target="RFC6313"/> to reduce
repetition of Object Identifier and indexing data.
</t>
<t>
To allow the use of individual columnar objects that make up a conceptual row,
a method is also specified to detail that a MIB object is indexed by
other fields in the same Data Flow.
For an individually indexed mibObjectValue the INDEX fields are sent
as any of the other fields in the same Record, and may be mibObjectValue
Information Element(s) or other existing Information Element(s).
</t>
<t>
Also, in some cases Exporters may not want (or be able) to export the full information on
how the MIB objects being exported are indexed. This may be because the MIB object
is being used purely as type information or the Exporting Process may not have knowledge
of the indexing required. Therefore providing index information for Columnar Objects is
optional.
</t>
</section> <!-- High level overview -->
<!-- PJ: this is section 5: -->
<section anchor="sectionMibObject" title="MIB Object Value Information Elements and the MIB Field Options Template">
<t>
This document defines new mibObjectValue Information Elements (in <xref target="sectionIANANewElementsValues"/>).
These are used to export MIB objects as part of standard IPFIX Templates.
The mibObjectValue Information Elements contain the actual data values.
</t>
<t>
The Metering or Exporting Process may extract the data values for mibObjectValue Information Elements from a Process that resides
on the same device or may capture or create the data required to match the definition of the MIB object. In particular
exporting a value of a MIB object defined in a certain MIB module does not imply that the SNMP process on the device supports that MIB module.
</t><t>
The main issue that arises from exporting values of MIB objects in IPFIX is that MIB Object Identifiers do not fit into the standard IPFIX
Template format <xref target="RFC7011"/>, as this only provides a 16-bit Information Element identifier.
</t><t>
The values of a MIB object could be exported using a MIB specific Information Element without providing any Object Identifiers.
However, without exporting the actual MIB OID the full type of the data would be unknown and every Field containing MIB object data would appear identical.
Without knowing which OID the contents of a field map to, the data would be incomprehensible to a Collector.
</t>
<t>
For the values in the mibObjectValue Information Elements to be understandable, more meta information about the mibObjectValue
Information Elements must be sent as part of the IPFIX export. The required minimum to understand each field is the OID as defined in <xref target="requiredMinimum"/>.
</t>
<t>
One approach to this problem would be to extend the IPFIX standard to allow extended field specifiers
so metadata about fields can be included in Data Templates. This would however require a new version
of the IPFIX standard which may not be backwards compatible. However, future versions of IPFIX may export the
required MIB metadata as part of newly defined IPFIX Set versions.
</t>
<t>
This document defines a MIB Field Options Template to export the extra meta information required for mibObjectValue Information Elements.
This is a standard IPFIX Options Template Set which includes a minimum set of required fields (see <xref target="requiredMinimum"/>)
and may include extra fields to provide more meta information about one of the mibObjectValue Information Elements.
</t>
<t>The MIB Field Options export is used to tell the Collecting process: for the following (template, field) the MIB Object type definition has this OID.</t>
<!-- CM: this is section 5.1: -->
<section anchor="sectionMIBFieldOptionArchitecture" title="MIB Field Options Architecture">
<t>
Four IPFIX Sets are used together to export a Flow which contains mibObjectValue Information Elements.
These are:
</t>
<t>
<list hangIndent="2" style="numbers">
<t>A Template Set which includes the mibObjectValue Information Element.
<list hangIndent="3" style="empty">
<t>
The Template Set informs the Collector that a MIB object value of length N will be exported. This Set may also be an Options Template Set.
</t>
</list>
</t>
<t>A MIB Field Options Template Set
<list hangIndent="3" style="empty">
<t>
The MIB Field Options Template describes which metadata will be sent for each mibObjectValue Information Element being exported.
</t>
</list>
</t>
<t>A MIB Field Options Data Set
<list hangIndent="3" style="empty">
<t>
The MIB Field Options Data Set includes the metadata for each MIB object (i.e., the mibObjectIdentifier or mibSubIdentifier).
The metadata about the mibObjectValue Information Elements only needs to be resent as per normal Template refreshes or resends.
</t>
</list>
</t>
<t>A Data Set.
<list hangIndent="3" style="empty">
<t>
The Data Set contains only the actual data extracted from the MIB or described by the MIB module.
</t>
</list>
</t>
</list>
</t>
<t>
<xref target="figure_mibFieldOptionIpfixMessage"/> shows the IPFIX Message structure for a MIB Field in a Template Set.
</t>
<figure align="center" anchor="figure_mibFieldOptionIpfixMessage"
title="IPFIX Message structure for a MIB Field in a Template Set">
<artwork align="center">
<![CDATA[+-------------------------------------------------------+
| IPFIX Message Header |
+-------------------------------------------------------+
| Template Set (A) |
+-------------------------------------------------------+
| Options Template Set (B) (MIB Field Options Template) |
+-------------------------------------------------------+
| Data Set (B) (MIB Field Options Data) |
+-------------------------------------------------------+
| Data Set (A) |
+-------------------------------------------------------+]]>
</artwork>
</figure>
<t>
The MIB Field Options Template defines MIB Field Options Data Records.
The MIB Field Options Data Records annotate the Data Template with mibObjectValue metadata.
Together the Data Template and MIB Field Options Data Records define the Data Records that will be exported.
</t>
<t>
The Data Records (A) have a dependency on the two Templates and the MIB Field Options Data Records.
</t>
<t>More Data Sets that use the same mibObjectValue Information Element can then be send in subsequent packets.</t>
<t><xref target="figure_RecordRelationshipDiagram"/>
shows the relationships between the Sets discussed above.</t>
<figure align="center" anchor="figure_RecordRelationshipDiagram"
title="Relationships between Sets">
<artwork align="center">
<![CDATA[ +------------------------------+
|MIB Field Options Template (B)|
+------------------------------+
|(templateId, elementIndex) |
+------------------------------+
| mibOID |
+------------------------------+
|
| Defines
V
+------------------------+ +--------------------------+
| Data Template (A) | |MIB Field Options Data (B)|
+------------------------+ +--------------------------+
|Field 0 - regular IE | | |
+------------------------+ +--------------------------+
|Field 1-mibObjectValue | <----------- | (X,1) = OID |
+------------------------+ Annotates +--------------------------+
|Field 2-mibObjectValue | <----------- | (X,2) = OID |
+------------------------+ +--------------------------+
| |
|------------------------------------/
|
| Defines
|
V
+------------------------+
| Data Records (A) |
|------------------------|
| Field 0 data |
+------------------------+
| Field 1 data |
+------------------------+
| Field 2 data |
+------------------------+]]>
</artwork>
</figure>
</section> <!-- Architecture -->
<!-- CM: this is section 5.3: -->
<section anchor="sectionDataModel" title="IPFIX and MIB Data Model">
<t><xref target="RFC2578"/> specifies that the SYNTAX clause for a MIB object defines the abstract data structure
of an Object and what it must contain:
</t>
<t>"The data structure must be one of the following: a base type, the BITS construct, or a textual
convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12)."
(From <xref target="RFC2578"/> section 7.1).
</t>
<t>For each of the SYNTAX clause options this document specifies exactly which mibObjectValue Information Element to use.</t>
<t>If a MIB object to be exported is a Textual Convention, the definition of the Textual Convention must be consulted and the
SYNTAX clause used to determine the correct base type. This may recurse if the Textual Convention is defined in terms of another
Textual Convention but this should end at a base type.</t>
<t>If the SYNTAX clause contains a Textual Convention or Subtyping the mibObjectSyntax Information Element SHOULD be used to export this detail to the Collecting Process.</t>
<t>The Options for the SYNTAX are then mapped as follows:</t>
<texttable anchor="dataModelTable" title="SMIv2 SYNTAX to mibObjectValue types">
<ttcol align="left">RFC2578 Section</ttcol>
<ttcol align="left">SYNTAX</ttcol>
<ttcol align="left">mibObjectValue IE</ttcol>
<c>7.1.1 </c><c> INTEGER/Integer32 </c><c> mibObjectValueInteger</c>
<c>7.1.2 </c><c> OCTET STRING </c><c> mibObjectValueOctetString</c>
<c>7.1.3 </c><c> OBJECT IDENTIFIER </c><c> mibObjectValueOID</c>
<c>7.1.4 </c><c> The BITS construct </c><c> mibObjectValueBits</c>
<c>7.1.5 </c><c> IpAddress </c><c> mibObjectValueIPAddress</c>
<c>7.1.6 </c><c> Counter32 </c><c> mibObjectValueCounter</c>
<c>7.1.7 </c><c> Gauge32 </c><c> mibObjectValueGauge</c>
<c>7.1.8 </c><c> TimeTicks </c><c> mibObjectValueTimeTicks</c>
<c>7.1.9 </c><c> Opaque </c><c> mibObjectValueOctetString</c>
<c>7.1.10 </c><c> Counter64 </c><c> mibObjectValueCounter</c>
<c>7.1.11 </c><c> Unsigned32 </c><c> mibObjectValueUnsigned</c>
<c>7.1.12 </c><c> SEQUENCE </c><c> mibObjectValueRow or</c>
<c> </c><c> </c><c> mibObjectValueTable</c>
</texttable>
<t>Values are encoded as per the standard IPFIX encoding of Abstract Data Types. The only new encoding reference in this document is that Object
Identifiers (OID) will be encoded as per ASN.1/BER <xref target="BER"/> in an octetArray.</t>
<t>The mibObjectValue and mibObjectIdentifier Information Elements are
standard IPFIX fields. Therefore the E bit of the mibObjectValue or
mibObjectIdentifier Information Elements is set to "0".
</t><t>
The MIB object being exported may be defined in an enterprise-specific
MIB module but the Information Elements defined in this
standard are still exported with the E bit set to "0". The OID
exported encodes that the MIB object was defined in a enterprise-specific MIB Module.
</t>
</section>
<!-- CM: this is section 5.2: -->
<section anchor="sectionMIBFieldOptionFormat" title="MIB Field Options - Specifications and Required Fields">
<t>
For each mibObjectValue Information Element that is defined in an IPFIX Template, a
MIB Field Options Data Record will be exported that provides the required minimum
information to define the MIB object that is being exported (see <xref target="requiredMinimum"/>).
</t><t>
The MIB Field Options Data Records are defined in a template referred to in this document as a MIB Field Options Template
with the format specified in <xref target="sectionFormats"/>.
</t>
<t>
The MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message
as any Template that is using a mibObjectValue Information Element.
Note that this places an implicit size constraint on the export.
</t>
<t>
This whole set of Templates and MIB Field Options Data Records MUST all be exported prior to the corresponding Data Records which depend upon them.
i.e., the export order MUST be:
<list style="numbers">
<t>Data Template for mibObjectValue Information Elements (Set ID 2)</t>
<t>MIB Field Options Template (Set ID 3)</t>
<t>MIB Field Options Data Records (Set ID >= 256)</t>
<t>MIB Object Value Data Records (Set ID >= 256)</t>
</list>
Note that the ID of an identical MIB Field Options Template which has already been exported MAY be reused without exporting the Template again.
</t>
<t>
IPFIX Set IDs are defined in section 3.3.2 of <xref target="RFC7011"/>. A value of 2 indicates a Template Set, a value of 3 indicates an Options Template Set, and values 256 and above indicate Data Sets.
</t>
<section anchor="requiredMinimum" title="MIB Field Options Template">
<t>
Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Information Element with a MIB Field Options Template:
<list style="symbols">
<t>(scope) templateId <xref target="IANA-IPFIX"/></t>
<t>(scope) informationElementIndex <xref target="IANA-IPFIX"/></t>
<t>mibObjectIdentifier (<xref target="mibObjectIdentifierIE"/>) or mibSubIdentifier (<xref target="mibSubIdentifierIE"/>)</t>
</list>
These are the minimum fields required in a MIB Field Options Template (see <xref target="sectionFormatMIBFieldOptionTemplate"/>).
</t>
<t>The mibObjectIdentifier is used to provide the OID for all mibObjectValue Information Elements exported except for when Structured
Data is being used to export a conceptual row (see <xref target="sectionExportingSequencesComplete"/>).
</t>
<t>
While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as described in the referenced sections:
<list style="symbols">
<t>mibCaptureTimeSemantics<vspace/>
(discussed in <xref target="sectionFormatMIBFieldOptionTemplateSemantics"/>;
IE defined in <xref target="mibCaptureTimeSemanticsIE"/>)
</t>
<t>mibIndexIndicator<vspace/>
(discussed in <xref target="sectionExportingSequencesExplicit"/>;
IE defined in <xref target="mibIndexIndicatorIE"/>)
</t>
<t>mibContextEngineID<vspace/>
(discussed in <xref target="sectionIdentifyingContext"/>;
IE defined in <xref target="mibContextEngineIDIE"/>)
</t>
<t>mibContextName<vspace/>
(discussed in <xref target="sectionIdentifyingContext"/>;
IE defined in <xref target="mibContextNameIE"/>)
</t>
</list>
</t>
</section>
<section anchor="requiredMinimumType" title="MIB Type Options Template">
<t>
There are also fields that provide type information from a MIB object definition that MAY be exported
to a Collecting Process.
</t>
<t>
Type information is statically defined in a MIB module; it is not
expected to change. However, the additional information about the
MIB object may help a Collecting Process that does not have access
to the MIB module.
</t>
<t>
To export a MIB Type Options Template, the mibObjectIdentifier is RECOMMENDED as a Scope Field so that it matches
the MIB Field Options Template. Any combination of the other MIB Type fields may be included.
<list style="symbols">
<t>(scope) mibObjectIdentifier (see <xref target="mibObjectIdentifierIE"/>)</t>
<t>mibObjectName (see <xref target="mibObjectNameIE"/>)</t>
<t>mibObjectDescription (see <xref target="mibObjectDescriptionIE"/>)</t>
<t>mibObjectSyntax (see <xref target="mibObjectSyntaxIE"/>)</t>
<t>mibModuleName (see <xref target="mibModuleName"/>)</t>
</list>
</t>
</section>
</section> <!-- MIB Field Option -->
<!-- CM: this is section 5.4: -->
<section anchor="sectionFormats" title="MIB Field Options Template Formats">
<!-- CM: this is section 5.3.1: -->
<section anchor="sectionFormatDataTemplate" title="Data Template containing a mibObject Field">
<t>
The Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard
IPFIX format as defined in <xref target="RFC7011"/>, so a field using a mibObjectValue Information Element is specified using standard IPFIX Field Specifiers as
in <xref target="RFC7011"/>.
</t>
<t>
The only extra requirement on a Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified
for EACH mibObjectValue Information Element (see <xref target="requiredMinimum"/>).
</t>
<t>
If Multiple MIB Field Options Data Records that refer to a mibObjectValue are received the latest MUST be used. This matches the
expected behavior of IPFIX Templates.
</t>
<t>
There is a one to one mapping between each mibObjectValue Information Element and a MIB Field Options Data Record.
</t>
<t>
A MIB Field Options Template and corresponding Data Record MUST be exported to provide the minimum required metadata.
</t>
<t>
<xref target="figure_FormatDataTemplate"/> shows an IPFIX Template Set using a mibObjectValue Information Element.
</t>
<figure align="center" anchor="figure_FormatDataTemplate"
title="IPFIX Template Set using mibObjectValue Information Element">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = Existing IPFIX Field | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = <mibObjectValue> | Field Length (MIB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>Where:
<list hangIndent="2" style="empty">
<t><mibObjectValue>
<list hangIndent="3" style="empty">
<t>
One of the mibObjectValue IPFIX Information Elements that denotes that a
MIB object data (i.e., the value of a MIB object)
will be exported in the (Options) Template Record.
</t><t>
This could be any one of the mibObjectValue Information Elements defined in <xref target="sectionIANANewElementsValues"/>:
mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueIPAddress, mibObjectValueBITS,
mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned,
mibObjectValueTable, and mibObjectValueRow.
</t>
<t>
When a mibObjectValue Information Element is used, the MIB Object Identifier ("mibObjectIdentifier")
MUST be exported via a MIB Field Options or by other means. See <xref target="requiredMinimum"/>.
</t>
</list>
</t>
<t>Field Length (MIB)
<list hangIndent="3" style="empty">
<t>
The length of the encoded MIB object data in the corresponding Data Records, in octets.
The definition is as <xref target="RFC7011"/>.
Note that the Field Length can be expressed using reduced size encoding per
<xref target="RFC7011"/>.
Note that the Field Length may be encoded using variable-length encoding per
<xref target="RFC7011"/>.
</t>
</list>
</t>
</list>
</t>
</section> <!-- sectionFormatDataTemplate -->
<!-- CM: this is section 5.3.2: -->
<section anchor="sectionFormatMIBFieldOptionTemplate" title="MIB Field Options Template">
<t>
The MIB Field Options Template is a Standard Options Template which defines the Fields that
will be exported to provide enough metadata about a mibObjectValue Information Element so that the Collector
can tie the data values in the mibObjectValue Information Element back to the definition of the MIB object.
</t>
<t>All MIB Field Options Templates contain the fields as specified in <xref target="requiredMinimum"/>.
</t>
<t>
<xref target="figure_mibFieldOptionTemplate"/> shows the required fields to export a mibObjectIdentifier for the MIB Field Options Template format.
</t>
<figure align="center" anchor="figure_mibFieldOptionTemplate"
title="MIB Field Options Template Format - Required Fields">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>templateId
<list hangIndent="3" style="empty">
<t>
The first Scope Field is an IPFIX Information Element which denotes that a Template Identifier
will be exported as part of the MIB Field Options Data Record. This Template Identifier paired with an index into
that template, the "informationElementIndex" field, uniquely references one mibObjectValue Information Element being exported.
</t>
</list>
</t>
<t>informationElementIndex
<list hangIndent="3" style="empty">
<t>
The second Scope Field is an IPFIX Information Element which denotes a zero based index
into the fields defined by a Template. When paired with a "templateId" the Record
uniquely references one mibObjectValue Information Element being exported.
</t>
</list>
</t>
<t>mibObjectIdentifier
<list hangIndent="3" style="empty">
<t>
An IPFIX Information Element which denotes the
a MIB Object Identifier for the mibObjectValue Information Element exported in the (Options) Template Record.
</t><t>
When a MIB Object Value Information Element is used,
the MIB Object Identifier MUST be specified in the MIB Field Options Template Record or specified by
other means.
</t><t>
The Object Identifier is encoded in the IPFIX data record in ASN.1/BER <xref target="BER"/> format.
</t><t>
Variable-length encoding SHOULD be used with the mibObjectIdentifier so that multiple different length
MIB OIDs can be exported efficiently. This will also allow reuse of the MIB Field Options Template.
</t><t>
Variable-length encoding is indicated by the Field Length value of 65535 per sections 3.2 and 7 of
<xref target="RFC7011"/>.
The RECOMMENDED use of variable length encoding for mibObjectIdentifier fields
is indicated in subsequent figures by placing 65535 in the relevant length fields.
</t>
</list>
</t>
</list>
</t>
</section>
<!-- CM: this is section 5.3.3: -->
<section anchor="sectionFormatMIBFieldDataRecords" title="MIB Field Options Data Records">
<t> The MIB Field Options Data Records conform to the Template Specification in the MIB Field Options Template.
There may be multiple MIB Field Options Data Records exported.</t>
<t>The Collecting Process MUST store all received MIB Field Options Data
information for the duration of each Transport Session, because the Collecting Process will need to refer to the
extra meta information to fully decode each mibObjectValue Information Element.
</t>
<t>
<xref target="figure_FormatMibFieldOptionDataRecord"/> shows the format of the exported MIB Field Options Data Record
detailing the metadata that will be exported to match the Template in <xref target="figure_mibFieldOptionTemplate"/>.
</t>
<figure align="center" anchor="figure_FormatMibFieldOptionDataRecord"
title="Format of MIB Field Options Data Record">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
<!-- CM: this is section 5.3.4: -->
<section anchor="sectionFormatOptionTemplate" title="Options Template containing a mibObject Field">
<t>
The Options Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard
format as defined in <xref target="RFC7011"/>. The mibObjectValue Information Element is specified using standard Field Specifiers as
in <xref target="RFC7011"/>.
</t>
<t>
A mibObjectValue Information Element can be either a Scope Field or a non-Scope Field in an Options Template Record.
</t>
<t>
The only extra requirement on a Options Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified
in <xref target="requiredMinimum"/> for EACH mibObjectValue Information Element.
</t>
<t>
An IPFIX Options Template Record MUST export a MIB Field Options Template and Data Record to provide the minimum required
metadata for each mibObjectValue Information Element.
</t>
<t>
<xref target="figure_FormatOptionTemplateNonScope"/> shows an IPFIX Options Template Set using an existing IPFIX Field as a Scope Field
and with a mibObjectValueInteger IE as a non-Scope Field,
while <xref target="figure_FormatObjectTemplateScope"/> shows an IPFIX Options Template Set using a mibObjectValueInteger IE as a Scope Field
with an existing IPFIX Field as a non-Scope Field.
</t>
<figure align="center" anchor="figure_FormatOptionTemplateNonScope"
title="IPFIX Options Template Set using a Non Scope mibObjectValueInteger Field">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_FormatObjectTemplateScope"
title="IPFIX Options Template Set using a Scope mibObjectValueInteger Field">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
<!-- CM: this is section 5.3.5: -->
<section anchor="sectionFormatMIBFieldOptionTemplateSemantics" title="MIB Field Options Template with Semantics Fields">
<t>A MIB Field Options Template MAY specify that extra Information Elements will be exported
to record how the mibObjectValue was collected.</t>
<t>Alternatively, one of the existing IPFIX observationTime* elements <xref target="IANA-IPFIX"/> may be exported
to specify exactly when the value was collected.</t>
<t>
<xref target="mibFieldOptionTemplateSemantics"/> shows the MIB Field Options Template for a non-columnar Field with Semantic Data.
</t>
<figure align="center" anchor="mibFieldOptionTemplateSemantics"
title="MIB Field Options Template for a non-indexed Field with Semantic Data">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibCaptureTimeSemantics|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>mibObjectIdentifier
<list hangIndent="3" style="empty">
<t>
Note the use of variable length encoding for this field.
</t>
</list>
</t>
<t>mibCaptureTimeSemantics
<list hangIndent="3" style="empty">
<t>
The MIB Capture Time Semantics IPFIX Information Element,
as defined in <xref target="mibCaptureTimeSemanticsIE"/>.
</t><t>
It is RECOMMENDED to include this field when exporting a mibObjectValue Information Element that specifies counters or statistics, in particular
for situations with long lived Flows.
</t>
</list>
</t>
</list>
</t>
</section> <!-- section Semantics -->
<!-- CM: this is section 5.3.6: -->
<section anchor="sectionFormatMIBFieldOptionTemplateObjectDetails" title="MIB Field Options Template with extra MIB Object Details">
<t>The OID exported within the mibObjectIdentifier IPFIX Information Element provides a OID reference
to a MIB object type definition that will fully describe the MIB object data being Exported.</t>
<t>However an Exported Process MAY decide to include some extra fields to more fully describe the
MIB Object that is being exported with a mibObjectValue Information Element.</t>
<t>This can be helpful if the Collecting Process may not have access to the MIB module.
</t>
<t>The Exporting Process can either include the extra object details fields as part of the MIB Field Options Template, or
export a separate Options Template and Data that maps MIB OIDs in mibObjectIdentifier Fields to the object details.</t>
<t>If only a few fields are being exported then including extra type data in the MIB Field Options export will be more
efficient.
</t>
<t>
The MIB Field Options Template for a non-indexed Field with extra MIB object details
is shown in <xref target="mibFieldOptionTemplateObjectDetails"/>.
</t>
<figure align="center" anchor="mibFieldOptionTemplateObjectDetails"
title="MIB Field Options Template for a non-indexed Field with extra MIB object details">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 38 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectSyntax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectDescription |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibModuleName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>mibObjectSyntax
<list hangIndent="3" style="empty">
<t>
The MIB object syntax string as defined in <xref target="mibObjectSyntaxIE"/>.
</t>
<t>
Note that a separate mibObjectSyntax Information Element is required
(rather than extend the existing informationElementDataType registry <xref target="IANA-IPFIX"/>)
because the SYNTAX clause could contain almost any name.
</t>
</list>
</t>
<t>mibObjectName
<list hangIndent="3" style="empty">
<t>
The textual name a mibObjectIdentifier Object.
</t>
</list>
</t>
<t>mibObjectDescription
<list hangIndent="3" style="empty">
<t>
The textual description for a mibObjectIdentifier.
</t>
</list>
</t>
<t>mibModuleName
<list hangIndent="3" style="empty">
<t>
The textual name of the MIB module that defines a MIB Object.
</t>
</list>
</t>
<t>Note the use of variable length encoding for the mibObjectIdentifier, mibObjectSyntax, mibObjectName, mibObjectDescription, and mibModuleName, since these are all string fields.
</t>
</list>
</t>
<t>The MIB details can be exported as an standard IPFIX Option export <xref target="RFC7011"/> as shown in <xref target="mibOidDetailsOption"/>. This may be more efficient as the bulk of this data is text based and SHOULD be exported only once
to the Collecting Process if there are many
MIB objects being exported. This prevents this large textual data being included for every use of a mibObjectValue Information Element.
</t>
<figure align="center" anchor="mibOidDetailsOption"
title="Alternative mibObjectIdentifier Option Export with object details">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectSyntax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibObjectDescription |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |0| IE = mibModuleName |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- section Semantics -->
</section> <!-- sectionFormats -->
<!-- CM: this is section 5.5: -->
<section anchor="sectionMIBFieldOptionOrdering" title="Use of field order in the MIB Field Option template">
<t>
The MIB Field Options Template export makes use of the informationElementIndex <xref target="IANA-IPFIX"/> to specify which
field in the template that the metadata relates to, which avoids any
ordering constraints on the data template. The mibObjectValue Information Elements in a IPFIX export can be in any order in the export packet.
However, fields used as an INDEX MUST be in the same order as specified in the INDEX clause of the conceptual row MIB object.
</t>
<t>
The informationElementIndex specifies which Field in the Template extra information is being provided for.</t>
<t>
This is analogous to standard IPFIX Template Sets which also specify the order
of the fields and provide their type and size.</t>
<t>
If the template changes such that the order is different then the
MIB Field Options data MUST be resent to reflect the new ordering. A new Template
ID MUST be used to reflect that the ordering has changed. Older
MIB Field Options Data may refer to the incorrect field.
</t>
<t>
A templateId <xref target="IANA-IPFIX"/> is only locally unique within a combination of a Observation Domain and Transport session. As such each
MIB Field Options Data Record can only refer to templateIds within the same Observation Domain and session.
</t>
</section> <!-- Use of field order -->
<!-- PJ: this is section 5.6: -->
<section anchor="sectionIdentifyingContext" title="Identifying the SNMP Context">
<t>
Each MIB OID is looked up in a specific context, usually the default context.
If exporting a MIB OID value that isn't in the default context then the
context MUST be identified by including the mibContextEngineID (see <xref target="mibContextEngineIDIE"/>)
and mibContextName (see <xref target="mibContextNameIE"/>) fields in the MIB Field Options Template and
associated MIB Field Options Data Records, or be included in the same template as the mibFieldValue Field.
</t>
<t>
This context data MUST be included for each field that is not in the default context.
</t>
<t>
The context information MAY be exported as part of the Template that includes the mibObjectValue Information Element
or the context information MAY be exported in the MIB Field Options Data Record that refers to the field. Context fields
exported in the same Template MUST take precedence over those that refer to the template. Context fields MUST apply to all
mibObjectValue Information Elements in the same template and there MUST NOT be duplicates of mibContextName or mibContextEngineID in
a Template.
</t>
<t>
So a MIB Field Options Template MAY specify no Context information, just the Context Engine ID or both the context engine and
context name. This allows the exporter to export the bulk of data in the default context and only tag those required.
</t>
<t> Since the MIB Field Options Template applies for all the records of a Template using Context Fields in the MIB Field Options Data Template requires that
each mibContextEngineID / mibContextName pair have its own Template.
</t>
</section> <!-- Identifying the SNMP Context -->
<!-- PJ: this is section 5.7: -->
<section anchor="sectionTemplateManagement" title="Template Management">
<t>
Templates are managed as per section 8 of <xref target="RFC7011"/> with the additional constraint
that the MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message
as any (Option) Template Record that uses a mibObjectValue Information Element.
</t> <t>
When exporting over an SCTP transport <xref target="RFC4960"/>, the MIB Field Options Data Records MUST be exported reliably and in the same SCTP stream as their associated Templates per <xref target="RFC6526"/>.
</t> <t>
If a Template using a mibObjectValue Information Element is resent for any reason the Records it depends on MUST be sent
as well.
</t><t>
If a Template is replaced with a new (Option) Template then a new MIB Field Options Data Record
MUST be sent with the replacement referencing the new Template ID.
</t><t>
An Exporting Process SHOULD reuse MIB Field Options Template IDs when the Templates are identical. Each
(Option) Template Record MUST still be accompanied by a copy of the MIB Field Options Template.
</t>
<section anchor="sectionLargeMessages" title="Large Messages">
<t>
The requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element may result in very large IPFIX Messages.
</t><t>
In environments with restricted Message sizes, and only when a reliable SCTP transport is being used, the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, MAY be exported in separate Messages in the same SCTP stream, provided that their order is maintained.
</t>
</section>
<section anchor="sectionTemplateWithdrawal" title="Template Withdrawal and Reuse">
<t>
Data Records containing mibObjectValue Information Elements MUST NOT be exported if their corresponding Data Template or MIB Field Options Template has been withdrawn, since the MIB Field Options Template MUST be exported in the same IPFIX Message as the Data Template which it annotates, except as allowed by the caveat of <xref target="sectionLargeMessages"/>.
</t><t>
MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates.
</t>
</section> <!-- Template Withdrawal -->
</section> <!-- Template Management -->
<!-- CM: this is section 5.8: -->
<section anchor="sectionExportingSequences" title="Exporting Conceptual Rows and Tables">
<t>
There are three approaches for an IPFIX Exporting Process to export the values of columnar objects:
</t>
<t>
<list hangIndent="5" style="numbers">
<t>Ignoring the indexing of Columnar Objects</t>
<t>Exporting conceptual rows/table objects using structured data</t>
<t>Exporting individual indexed Columnar Objects</t>
</list>
</t>
<t>Firstly, a subordinate columnar object may be used purely as a data type.
In this case there is no index information or relation to a conceptual row object provided by the Exporting Process.</t>
<t>Secondly, mibObjectValueRow or mibObjectValueTable can be used to export partial or complete conceptual rows using <xref target="RFC6313"/> structured data.</t>
<t>Thirdly, in a mixed option/data IPFIX/MIB template, the
mibObjectValue Information Element can have the values of
the INDEX clause of the conceptual row provided by other
fields in the record. In this case each mibObjectValue
Information Element must specify which other field(s) in the template is
providing the index information.</t>
<!-- subsection 5.7.1 -->
<section anchor="sectionExportingSequencesIndexing" title="Exporting Conceptual Rows - indexing">
<t>This document defines two forms of indexing that can be used for conceptual row MIB objects.</t>
<t>Structured Data based indexing is used solely by the mibObjectValueRow Information Element. Each conceptual row of the
MIB object corresponds to a single Data Record exported. The index fields defined in the INDEX clause of the MIB object MUST all be present
in the same order as the Scope Fields. This allows a simple table export of a conceptual row MIB object without any extra fields required to indicate which fields
make up the conceptual row INDEX.</t>
<t>Field based indexing is used by giving each mibObjectValue Information Element a mibIndexIndicator to flag the required index fields.
This allows complex indexing or mixing of existing IPFIX Information Element with MIB Fields with minimum overhead.
It also allows multiple Columnar MIB objects from different conceptual rows to be exported with complete indexing in one IPFIX Template.</t>
</section>
<!-- subsection 5.7.2 -->
<section anchor="sectionExportingSequencesComplete" title="Exporting Conceptual Rows - mibObjectValueRow">
<t>
The simplest approach to exporting a complete or partial conceptual row object is done with the mibObjectValueRow Information Element.</t>
<t>This is a Structured Data subTemplateList Information Element as detailed in <xref target="RFC6313"/>. The template specified MUST be an Options Template. It also MUST have the fields specified in the INDEX clause
of the conceptual row object as the Scope Fields for the Option Export.
</t>
<t>An overview of this architecture is given in <xref target="figure_exporting_sequences_architecture"/>. This shows that the full MIB object type definition OID is exported for the
mibObjectValueRow conceptual row field but that the individual columnar objects only require the subIdentifier to be exported. To make the diagram clearer the Templates for
the MIB Field Options Templates are not shown.</t>
<figure align="center" anchor="figure_exporting_sequences_architecture"
title="Architecture for Exporting Conceptual Rows with mibObjectValueRow">
<artwork align="center">
<![CDATA[
+---------------------------+ +------------------------+
| Data Template | | MIB Field Options Data |
| | | |
| mibObjectValueRow |<---| OID |
+---------------------------+ +------------------------+
|
| +-----------------------+ +------------------------+
| | Options Template | | MIB Field Options Data |
| | | | |
| | Scope mibObjectValue* |<---| subIdentifiers |
| | mibObjectValue* |<---| subIdentifiers |
| +-----------------------+ +------------------------+
| |
V V
+---------------------------+
| Data Flows |
| |
| subTemplateList (1 entry) |
+---------------------------+
]]>
</artwork>
</figure>
<t>
The mibIndexIndicator is not required for each individual mibObjectValue
Information Element as mibObjectValueRow provides a structure that includes the
index details.
</t>
<t>
When Structured Data based indexing is used all Scope Fields MUST be the INDEX
Objects in the same order as defined in the INDEX clause of the conceptual row
being exported. </t>
<t>
Each conceptual table MIB object has 2 related OIDs. There is an OID that refers to the Table with syntax of SEQUENCE OF and an OID that
refers to each entry or conceptual row with the syntax of SEQUENCE. The OID for the SEQUENCE of a conceptual row MUST be exported.
</t>
<t>
For example in the IF-MIB (<xref target="RFC2863"/>) the OID for ifEntry should be exported rather than the OID for ifTable. The OID for the table (in this case ifTable) can
be derived by removing one subidentifier from the ifEntry OID.
</t>
<t>The Full OID for the conceptual row MIB object type definition being exported with the mibObjectValueRow Information Element MUST be exported.
However the fields that are members of the conceptual row need not have the full OID of their MIB object type definition exported. Instead the mibSubIdentifier Information Element can be used to document which entry in the conceptual row the Field is.
</t>
<t>In this case the export flow will contain a single complete or partial row from a table inside a single field of the record.</t>
<t>
There may be MIB objects that are specified in the INDEX of the conceptual row but not columnar objects of the same conceptual row, for these the Exporter MUST provide the full OID
in a mibObjectIdentifier field.</t>
<t> So for a conceptual row object with the OID "1.2.3.4.5.6" the OID of the type definitions for columnar objects "1.2.3.4.5.6.1" "1.2.3.4.5.6.2" can be exported with just a subIdentifier of "1" and "2" respectively.
</t><t>The mibObjectValue Information Elements exported using the mibObjectValueRow export
MUST all either be Objects defined in the INDEX clause, Columnar Objects of the same
conceptual row object or Columnar Objects that AUGMENT the same conceptual row. </t>
<t>The <xref target="RFC6313"/> Structured Data subTemplateList format requires a Structured Data Type Semantic to be specified. Unless there is a more appropriate
option in the IPFIX Structured Data Types Semantics registry (<xref target="IANA-IPFIX-SDTS"/>) the "undefined" Structured Data Type Semantic can be used.</t>
<t>
<xref target="figure_mibSequenceExport"/> shows an IPFIX Template for a Structured Data export of a conceptual row, while
<xref target="figure_mibSequenceOptionTemplate"/> shows an IPFIX Options Template for a complete conceptual row with five columns and two INDEX fields.
<xref target="sequenceMibFieldOptionTemplate"/> shows the MIB Field Options Template for a conceptual row field.
<xref target="sequenceMibSubFieldOptionTemplate"/> shows the MIB Field Options Template for the columns inside the conceptual row.
<xref target="mibSequenceOIDData"/> shows the OID data for the conceptual row would be exported.
</t>
<figure align="center" anchor="figure_mibSequenceExport"
title="IPFIX Template for a Conceptual Row">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 300 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_mibSequenceOptionTemplate"
title="IPFIX Options Template for a mibObjectValueRow with 5 columns and 2 INDEX fields">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 301 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValue INDEX1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue INDEX2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUM3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUM4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = mibObjectValue COLUM5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="sequenceMibFieldOptionTemplate"
title="MIB Field Options Template for a Conceptual Row Object">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 302 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>templateId
<list hangIndent="3" style="empty">
<t>
The templateId for the MIB Option that will be exported.
</t>
</list>
</t>
<t>mibObjectIdentifier
<list hangIndent="3" style="empty">
<t>
The MIB OID for the Conceptual Row that is being exported.
Note the use of variable length encoding for this field.
</t>
</list>
</t>
</list>
</t>
<figure align="center" anchor="sequenceMibSubFieldOptionTemplate"
title="MIB Field Options Template for Columnar Objects of a Conceptual Table">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 303 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>templateId
<list hangIndent="3" style="empty">
<t>
The templateId used will be for the Template referred to in the subTemplateList of the mibObjectValueRow that will be exported.
</t>
</list>
</t>
<t>mibSubIdentifier
<list hangIndent="3" style="empty">
<t>
The sub identifier that specifies the columnar object's ID within the conceptual row.
</t>
</list>
</t>
</list>
</t>
<figure align="center" anchor="mibSequenceOIDData"
title="mibOption Data Record for the conceptual row">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 302 | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 300 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 303 | Length = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier | templateId = 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex | mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier | templateId = 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex | mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 301 | informationElementIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>mibObjectIdentifier
<list hangIndent="3" style="empty">
<t>
Will contain the OID for the conceptual row as a whole.
</t>
</list>
</t>
<t>mibSubIdentifier
<list hangIndent="3" style="empty">
<t>
The mibSubIdentifier fields will contain the extra Sub Identifier that when
added to the OID for the conceptual row give the full OID for the Object.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="sectionExportingSequencesAugments" title="Exporting Conceptual Rows - Augments">
<t>SMIv2 defines conceptual rows as either having an INDEX clause or an AUGMENTS clause.
Conceptual row definitions with an AUGMENTS clause extend an existing base conceptual row with an
INDEX clause. It is not possible in SMIv2 to AUGMENT a conceptual row that itself has
an AUGMENTS clause. The base table and the augmentation have an identical INDEX.
</t>
<t>Since augmentations allow adding extra columns to existing tables it is beneficial to be able
to support them easily in IPFIX exports of conceptual rows.
</t>
<t>The mibObjectValueRow OID MAY refer either to the base table with the INDEX clause, or to a
conceptual row with an AUGMENTS clause. The subIdentifiers in any MIB Field Options Data Record MUST always refer to
the OID exported for the mibObjectValueRow IE.
</t>
<t>
If the mibObjectValueRow OID refers to a base table then any extra columns from conceptual rows with
an AUGMENTS clause MUST have their full OID exported.
</t>
<t>If the mibObjectValueRow OID refers to a conceptual row that augments another conceptual row using the AUGMENTS
clause then any MIB fields from the original table's INDEX or Columnar Objects MUST NOT use
the mibSubIdentifier and MUST instead export the full OID in a mibObjectIdentifier.
</t> <t>
If the mibObjectValueRow refers to an AUGMENTS
conceptual row the Scope Fields of the Template using in the
subTemplateList MUST have the INDEX fields from the base
table, in the same order as its scope. This is
identical to the Scope Field requirements for conceptual rows
with an INDEX clause.
</t>
<t>This flexibility is provided so that the conceptual rows with the most columns can be exported using the more
efficient mibSubIdentifier. For example exporting a complete set of augmentation columns would only require
the full OIDs for the MIB objects in the INDEX.
</t>
<t>
It is possible to export MIB object columns from multiple AUGMENTS conceptual rows. If this is done then the base
table SHOULD be used as the main OID for the mibObjectValueRow.
</t> </section>
<section anchor="sectionExportingSequenceOF" title="Exporting Conceptual Tables - mibObjectValueTable">
<t>
Multiple rows of a conceptual table can be exported in the mibObjectValueTable Information Element (<xref target="mibObjectValueTableIE"/>). This allows
a set of conceptual rows corresponding to a conceptual table to be exported as a single field. Therefore a complete set of rows can be exported as a single
field with other information elements in a Template. In this fashion several complete conceptual tables could be exported in one packet.
</t>
<t>Identically with mibObjectValueRow, as in section <xref target="sectionExportingSequencesComplete"/> above, the more specific OID of the SEQUENCE entity MUST be exported.
</t>
<t>
The format of mibObjectValueTable is identical to mibObjectValueRow except that the length of the subTemplateList may be 0 or more entries.
</t>
<t>
All the other, non length, requirements for mibObjectValueRow in <xref target="sectionExportingSequencesComplete"/> apply to mibObjectValueTable.
</t>
<t>An overview of this architecture is given in <xref target="figure_exporting_sequences_architecture_table"/>. This shows the similarity to <xref target="figure_exporting_sequences_architecture"/>
</t>
<figure align="center" anchor="figure_exporting_sequences_architecture_table"
title="Architecture for Exporting Conceptual Tables with mibObjectValueTable">
<artwork align="center">
<![CDATA[
+---------------------------+ +------------------------+
| Data Template | | MIB Field Options Data |
| | | |
| mibObjectValueTable |<---| OID |
+---------------------------+ +------------------------+
|
| +-----------------------+ +------------------------+
| | Options Template | | MIB Field Options Data |
| | | | |
| | Scope mibObjectValue* |<---| subIdentifiers |
| | mibObjectValue* |<---| subIdentifiers |
| +-----------------------+ +------------------------+
| |
V V
+-----------------------------+
| Data Flows |
| |
| subTemplateList (n entries) |
| row 1 |
| ... |
| row n |
+-----------------------------+
]]>
</artwork>
</figure>
</section>
<section anchor="sectionExportingSequencesExplicit" title="Exporting Columnar Objects - using mibIndexIndicator">
<t>
The other option for indexing a Columnar Object that is part of a conceptual table is explicit indexing. In this case
there may be non index fields in the scope of the option export or there may be
columnar MIB objects from multiple conceptual rows being exported. In this case each
mibObjectValue Information Element requires the mibIndexIndicator with the bits set for the fields that
are used to index that individual columnar object.
</t><t>The index fields MUST be in the 'correct' order as
defined in the conceptual row that each columnar object is a member of.
</t>
<t>If a mibObjectValue Information Element that is being indexed using mibIndexIndicator is being used as an Options Template Scope Field, then all
fields used to index that field MUST also be Scope Fields.</t>
<t>
<xref target="mibFieldOptionTemplateIndexed"/> shows the MIB Field Options Template for an indexed MIB Columnar Object.
</t>
<figure align="center" anchor="mibFieldOptionTemplateIndexed"
title="MIB Field Options Template for an indexed MIB Columnar Object">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>mibIndexIndicator
<list hangIndent="3" style="empty">
<t>
The MIB Index Indicator IPFIX Information Element which marks which fields in the record will act
as INDEX values for the exported MIB object.
</t><t>
The index data for a mibObjectValue will be other
fields contained in the same Data Record.
The mibIndexIndicator marks the Fields whose value(s) should
be added to the OID for the MIB object type definition
exported in mibObjectIdentifier to get the OID for the instance
of the MIB object.
</t>
<t>Elements used to index MIB objects MUST be exported in the same order as they are specified
in the INDEX field of the conceptual table they belong to.
</t>
</list>
</t>
<t>mibObjectIdentifier
<list hangIndent="3" style="empty">
<t>
Note the use of variable length encoding for this field.
</t>
</list>
</t>
</list>
</t>
</section> <!-- Indexed Template -->
</section> <!-- Sequence -->
</section> <!-- MIB OID Extended Template Record Formats -->
<!-- PJ: this is section 6: -->
<section anchor="sectionExampleUseCases" title="Example Use Cases">
<!-- CM: this is section 6.1: -->
<section anchor="sectionUseCaseTcpCurrEstab" title="Non Columnar MIB Object: Established TCP Connections">
<t>
The number of established TCP connections of a remote network device
could be monitored by configuring it to periodically export the number
of established TCP connections to a centralized Collector. In this
example, the Exporter would export an IPFIX Message every 30 minutes
that contained Data Records detailing the number of established TCP
connections. </t>
<t>
The table of data that is to be exported looks like:
</t>
<texttable anchor="TCP_Usage_Data" title="Established TCP Connections">
<ttcol align="center">TIMESTAMP</ttcol>
<ttcol align="center">ESTABLISHED TCP CONN.</ttcol>
<c>StartTime + 0 seconds</c><c>10</c>
<c>StartTime + 60 seconds</c><c>14</c>
<c>StartTime + 120 seconds</c><c>19</c>
<c>StartTime + 180 seconds</c><c>16</c>
<c>StartTime + 240 seconds</c><c>23</c>
<c>StartTime + 300 seconds</c><c>29</c>
</texttable>
<t>
The Template Record for such a Data Record will detail two Information Elements:
</t>
<t>
<list hangIndent="2" style="numbers">
<t>
flowStartSeconds from <xref target="IANA-IPFIX"/>, Information Element 150: The absolute timestamp of the first packet of this Flow.
</t>
<t>
tcpCurrEstab from <xref target="RFC4022"/>, Object ID "1.3.6.1.2.1.6.9": The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT.
</t>
</list>
</t>
<t>
<xref target="figure_ExampleTemplateSet_tcpCurrEstab"/> shows the exported Template Set
detailing the Template Record for exporting the number of established TCP connections.
</t>
<figure align="center" anchor="figure_ExampleTemplateSet_tcpCurrEstab"
title="Example of tcpCurrEstab Template Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 400 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionTemplateSet_tcpCurrEstab"/> shows the exported MIB Field Options Template Set
detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionTemplateSet_tcpCurrEstab"
title="Example of tcpCurrEstab MIB Field Options Template Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 401 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionDataSet_tcpCurrEstab"/> shows the exported MIB Field Options Data Set
detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record.
</t>
<t>The OID for the MIB object tcpCurrEstab from <xref target="RFC4022"/>, Object ID "1.3.6.1.2.1.6.9", will be encoded in ASN.1/BER <xref target="BER"/> as '06072b060102010609' in the
data record, which takes nine octets.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionDataSet_tcpCurrEstab"
title="Example of tcpCurrEstab MIB Field Options Data Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 401 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 400 | informationElementIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=9 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 06072b060102010609 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleDataSet_tcpCurrEstab"/> shows the start of the Data Set for exporting the number of established TCP connections (see <xref target="sectionUseCaseTcpCurrEstab" />).
</t>
<figure align="center" anchor="figure_ExampleDataSet_tcpCurrEstab"
title="Example of tcpCurrEstab Data Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 400 | Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 0 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 60 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 120 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 180 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 240 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StartTime + 300 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- Non-indexed MIB Object: Established TCP Connections -->
<!-- CM: this is section 6.2: -->
<section anchor="sectionUseCaseCpuLoad" title="Enterprise Specific MIB Object: Detailing CPU Load History">
<t>
For the sake of demonstrating a enterprise-specific MIB object from the CISCO-PROCESS-MIB (<xref target="CISCO-PROCESS-MIB"/>)
is chosen. This example would be valid with any enterprise-specific MIB module.
</t><t>
The CPU Usage of a remote network device with 1 CPU
could be monitored by configuring it to periodically export CPU usage
information, i.e., the cpmCPUTotal1minRev from the proprietary
CISCO-PROCESS-MIB, Object ID "1.3.6.1.4.1.9.9.109.1.1.1.1.7", to a centralized
Collector.
</t>
<t>
Although the cpmCPUTotal1minRev MIB object is a columnar object in a conceptual row, while there
is only 1 CPU no extra information is conveyed by providing the INDEX field. So in this case it is
acceptable to not export the cpmCPUTotalIndex MIB object. If there were multiple CPUs it would be appropriate
to include this the cpmCPUTotalIndex field and specify the relationship.
</t>
<t>In this example, the Exporter would export an IPFIX Message every
30 minutes that contained Data Records detailing the CPU 1 minute busy average
at 1 minute intervals.
</t>
<t>
The table of data that is to be exported looks like:
</t>
<texttable anchor="CPU_Usage_Data" title="CPU Usage Data">
<ttcol align="center">TIMESTAMP</ttcol>
<ttcol align="center">CPU BUSY PERCENTAGE</ttcol>
<c>StartTime + 0 seconds</c><c>10%</c>
<c>StartTime + 60 seconds</c><c>14%</c>
<c>StartTime + 120 seconds</c><c>19%</c>
<c>StartTime + 180 seconds</c><c>16%</c>
<c>StartTime + 240 seconds</c><c>23%</c>
<c>StartTime + 300 seconds</c><c>29%</c>
</texttable>
<t>
The Template Record for such a Data Record will detail two Information Elements:
</t>
<t>
<list hangIndent="2" style="numbers">
<t>
flowStartSeconds from <xref target="IANA-IPFIX"/>, Information Element 150: The absolute timestamp of the first packet of this Flow.
</t>
<t>
a mibObjectValueGauge for cpmCPUTotal1minRev, the overall CPU busy percentage in the last one-minute period.
</t>
</list>
</t>
<t>
<xref target="figure_ExampleTemplateSet_CPULoad"/> shows the exported Template Set
detailing the Template Record for exporting CPU Load (see <xref target="sectionUseCaseCpuLoad"/>).
</t>
<figure align="center" anchor="figure_ExampleTemplateSet_CPULoad"
title="Example of CPU Load Template Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 402 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = flowStartSeconds | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionTemplateSet_CPULoad"/> shows the exported Template Set
detailing the MIB Field Options Template for exporting CPU Load (see <xref target="sectionUseCaseCpuLoad"/>).
Note this is identical to the MIB Field Options Template given in <xref target="figure_ExampleMibFieldOptionTemplateSet_tcpCurrEstab"/>
so the same template could have been reused.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionTemplateSet_CPULoad"
title="Example of CPU Load MIB Field Options Template Set ">
<artwork align="center">
<![CDATA[ 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 403 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionDataSet_CPULoad"/> shows the exported MIB Field Options Data Set
detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 402 in Template Record (see <xref target="sectionUseCaseCpuLoad"/>).
</t>
<t>The OID for the cpmCPUTotal1minRev has been encoded using ASN.1/BER to '060d2b0601040109096d0101010107' at 15 octets long.</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionDataSet_CPULoad"
title="Example of CPULoad MIB Field Options Data Set">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 403 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 402 | informationElementIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=15 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.4.1.9.9.109.1.1.1.1.7" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060d2b0601040109096d0101010107 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Note that although cpmCPUTotal1minRev is 32 bits long, reduced size encoding <xref target="RFC7011"/> has been used to encode it within a single octet.
The encoding size was specified by setting the length for the mibObjectValueGauge Field to 1 octet in the main Data Template - <xref target="figure_ExampleTemplateSet_CPULoad"/>.
</t>
<t>
This example stresses that, even though the OID cpmCPUTotal1minRev is enterprise-specific, the E bit for the mibObjectValueGauge and mibObjectIdentifier is set to "0"
since the "mibObjectValueGauge" and "mibObjectIdentifier" Information Element is not enterprise-specific. That this data is from an Enterprise MIB is included in the OID
that includes an Enterprise ID.
</t>
<t>
The corresponding Data Set does not add any value for this example, and is therefore not displayed.
</t>
</section> <!-- Non-indexed MIB Object: Detailing CPU Load History -->
<section anchor="sectionUseCaseSequence"
title="Exporting a Conceptual Row: The OSPF Neighbor Row">
<t>Many conceptual tables are already defined in standard and proprietary MIBs. These can be exported
with a minimum of overhead by using the mibObjectValueRow.
This allows the Exporting Process to unambiguously define
the INDEX for the entire conceptual row as the Scope Fields of an Option Export.
The use of a MIB Field Options Template with mibSubIdentifier being used means that each individual
columnar object does not need to have its OID exported to the collector</t>
<t>The ospfNbrTable defined in the OSPF MIB <xref target="RFC4750"/> consists of ospfNbrEntry, which has the OID "1.3.6.1.2.1.14.10.1".
Each mibObjectValueRow data record will therefore correspond to an ospfNbrEntry.</t>
<t>The following fields will be exported:</t>
<texttable anchor="ospfNbrEntryObjects" title="OSPF Neighbor Entry Objects">
<ttcol align="left">Object</ttcol>
<ttcol align="left">ID</ttcol>
<ttcol align="left">mibObjectValue</ttcol>
<ttcol align="center">Len</ttcol>
<c>ospfNbrIpAddr </c><c>ospfNbrEntry 1</c> <c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrAddress- </c><c>ospfNbrEntry 2</c> <c>mibObjectValueInteger </c><c>4</c>
<c>-LessIndex </c><c/><c/><c/>
<c>ospfNbrRtrId </c><c>ospfNbrEntry 3</c> <c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrState </c><c>ospfNbrEntry 6</c> <c>mibObjectValueInteger </c><c>1</c>
</texttable>
<t>The OIDs that will be used to export this table are shown in <xref target="ospfNbrOIDs"/>.</t>
<texttable anchor="ospfNbrOIDs" title="OSPF OIDs">
<ttcol align="left">Entity</ttcol>
<ttcol align="left">Full OID</ttcol>
<ttcol align="left">Exported as</ttcol>
<c>ospfNbrEntry </c><c>1.3.6.1.2.1.14.10.1 </c> <c>1.3.6.1.2.1.14.10.1</c>
<c>ospfNbrIpAddr </c><c>1.3.6.1.2.1.14.10.1.1</c> <c>1</c>
<c>ospfNbrAddress- </c><c>1.3.6.1.2.1.14.10.1.2</c> <c>2</c>
<c>-LessIndex </c><c/><c/>
<c>ospfNbrRtrId </c><c>1.3.6.1.2.1.14.10.1.3</c> <c>3</c>
<c>ospfNbrState </c><c>1.3.6.1.2.1.14.10.1.6</c> <c>6</c>
</texttable>
<t>
<xref target="figure_Example_Templates_ospfNbrEntry"/> shows the Templates Exported to Support the mibObjectValueRow.
<xref target="figure_Example_OIDData_ospfNbrEntry"/> shows the example OID Data for the conceptual row exported in mibObjectValueRow
<xref target="figure_Example_Data_ospfNbrEntry"/> shows the example data export for a few neighbors in the table.
This shows a Data Record in formatted as per IPFIX Structured Data <xref target="RFC6313"/> and using the the
'undefined' (= 0xFF) semantic <xref target="IANA-IPFIX-SDTS"/>.
Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long.
</t>
<figure align="center" anchor="figure_Example_Templates_ospfNbrEntry"
title="Example of ospfNbrEntry Template and Options Template Sets">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 500 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 501 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 502 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 503 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_OIDData_ospfNbrEntry"
title="Example of ospfNbrEntry OID Data export">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 502 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 500 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B060102010E0A01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 503 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 501 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 501 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 501 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 3 | templateId = 501 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 3 | mibSubIdentifier = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_Data_ospfNbrEntry"
title="Example of Data Export for ospfNbrEntry">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 500 | Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 501 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 3.3.3.3 |ospfNbrState=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
<section anchor="sectionUseCaseAugments"
title="Exporting Augmented Conceptual Row: The IF-MIB id to name mapping">
<t>The ifTable defined in the <xref target="RFC2863"/> is augmented by the
ifXTable (defined in the same MIB module).</t>
<t>The OID of the ifEntry is 1.3.6.1.2.1.2.2.1 which is encoded using ASN.1/BER to '06082B06010201020201' at 10 octets long, while the OID of the augmenting ifXEntry is 1.3.6.1.2.1.31.1.1.1 which is encoded using ASN.1/BER to '060a2b060102011f01010101' at 12 octets long.
</t>
<t>This example demonstrates how
columnar objects from the base conceptual row and the augmenting
row can be exported in a single mibObjectValueRow Information Element.</t>
<t><xref target="ifMIBIdName"/> shows the fields which will be exported.</t>
<texttable anchor="ifMIBIdName" title="IF-MIB Data">
<ttcol align="left">ifIndex</ttcol>
<ttcol align="left">ifType</ttcol>
<ttcol align="left">ifMtu</ttcol>
<ttcol align="left">ifName</ttcol>
<c>1 </c><c>ethernetCsmacd:6</c> <c>1500</c><c>Ethernet 10 </c>
<c>2 </c><c>ethernetCsmacd:6</c> <c>1500</c><c>Ethernet 20 </c>
<c>3 </c><c>ethernetCsmacd:6</c> <c>1500</c><c>FastEthernet 30 </c>
</texttable>
<t>The OIDs that will be used to export this table are shown in <xref target="ifMIBOIDs"/>.</t>
<texttable anchor="ifMIBOIDs" title="IF-MIB OIDs">
<ttcol align="left">Entity</ttcol>
<ttcol align="left">Full OID</ttcol>
<ttcol align="left">Exported as</ttcol>
<c>ifEntry</c><c>1.3.6.1.2.1.2.2.1 </c> <c>OID = 1.3.6.1.2.1.2.2.1</c>
<c>ifIndex</c><c>1.3.6.1.2.1.2.2.1.1</c> <c>subID = 1</c>
<c>ifType </c><c>1.3.6.1.2.1.2.2.1.3</c> <c>subID = 3</c>
<c>ifMtu </c><c>1.3.6.1.2.1.2.2.1.4</c> <c>subID = 4</c>
<c>ifName </c><c>1.3.6.1.2.1.31.1.1.1.1</c> <c>OID = 1.3.6.1.2.1.31.1.1.1.1</c>
</texttable>
<t>
<xref target="figure_Example_Templates_ifMIB"/> shows the Templates Exported to Support the mibObjectValueRow Information Element.
<xref target="figure_Example_OIDData_ifMIB"/> shows the example OID Data for the conceptual row exported in mibObjectValueRow to match <xref target="ifMIBOIDs"/>.
<xref target="figure_Example_Data_ifMIB"/> shows the example data export as per <xref target="ifMIBIdName"/>.
</t>
<figure align="center" anchor="figure_Example_Templates_ifMIB"
title="Example of Augmented ifEntry Template and Options Template Sets">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 600 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 601 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|IE =mibObjectValueOctetString|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 602 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 603 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_OIDData_ifMIB"
title="Example of Augmented ifEntry OID Data export">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 602 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 600 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=10 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifEntry = 1.3.6.1.2.1.2.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B06010201020201 | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=12 | mibObjectIdentifier ifName ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifName = 1.3.6.1.2.1.31.1.1.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060a2b060102011f01010101 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 603 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 601 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 601 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_Data_ifMIB"
title="Example of Data Export for Augmented ifEntry">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 600 | Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length = 11 | ifName = Ethernet 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length = 11 | ifName = Ethernet 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 601 | ifIndex = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifType = 6 | ifMtu = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length = 15 | ifName = FastEthernet 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
<!-- PJ: this is section 6.4: -->
<section anchor="sectionUseCaseSequenceSelectedObject"
title="Exporting a Columnar Object: The ipIfStatsInForwDatagrams">
<t>It may be that the full set of columnar objects that are supported by a conceptual row are
not required to be exported. Rather than use the Structured Data method the mibIndexIndicator method can
be used to provide the relation between fields.
</t><t>This example shows the MIB Objects that are part of the INDEX of the conceptual row being exported
in the correct order and then being referred to by using mibIndexIndicator.
</t>
<t>
This example shows the export of ipIfStatsInForwDatagrams from the IP-MIB <xref target="RFC4293"/>.
ipIfStatsInForwDatagrams is a columnar object that is part of the conceptual table ipIfStatsTable. This is comprised
of ipIfStatsEntry conceptual rows.
</t>
<t>
The ipIfStatsTable conceptual table is indexed by the ipIfStatsIPVersion and ipIfStatsIfIndex.</t>
<t>
The Options Template Record for the example Data Record contains the following Information Elements:
</t>
<t>
<list hangIndent="2" style="numbers">
<t>
ipIfStatsIPVersion (1.3.6.1.2.1.4.31.3.1.1) (Scope Field)<vspace/>
(encoded using ASN.1/BER to '060A2B06010201041F030101' at 12 octets long)
</t>
<t>
ipIfStatsIfIndex (1.3.6.1.2.1.4.31.3.1.2) (Scope Field)<vspace/>
(encoded using ASN.1/BER to '060A2B06010201041F030102' at 12 octets long)
</t>
<t>
ipIfStatsInForwDatagrams (1.3.6.1.2.1.4.31.3.1.12) (non-Scope Field)<vspace/>
(encoded using ASN.1/BER to '060A2B06010201041F03010c' at 12 octets long)
</t>
</list>
</t>
<t>Note ipIfStatsIfIndex has been reduce length encoded to 2 octets in the following example. An exporting device
with more interfaces would use the full length.
</t>
<t>
<xref target="figure_ExampleTemplateSet_2indices"/> shows the exported Options Template Set.
</t>
<figure align="center" anchor="figure_ExampleTemplateSet_2indices"
title="Example of an Options Template for an Indexed MIB Object with two indices.">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 701 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0|Scope 1=mibObjectValueInteger|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field 1 Length = 1 |0|Scope 2=mibObjectValueInteger|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field 1 Length = 2 |0| IE = mibObjectValueCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionTemplateSet_2indices"/> shows the exported MIB Field Options Template used to export
the required mibObjectValue Information Element metadata. This example of the MIB Field Options Template includes the mibIndexIndicator to indicate that
some of the other fields in the data records are indexes.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionTemplateSet_2indices"
title="Example of an MIB Field Options Template for an Indexed MIB Object with two indices.">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 702 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionDataSet_2indices"/> shows the exported MIB Field Options Data used to export
the required mibObjectValue Information Element metadata. Note that the first two Data Records have all their mibIndexIndicator bits set to 0.
The third mibIndexIndicator has the value '11000000' to show that the first two fields in the record are the
INDEX's for this columnar object.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionDataSet_2indices"
title="Example of an MIB Field Options Data Set for an Indexed MIB Object with two indices.">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 702 | Length = 58 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 701 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00000000 | VLEN = 12 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.1" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F030101 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | templateId = 701 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 |Index 00000000 | VLEN = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibObjectIdentifier = "1.3.6.1.2.1.4.31.3.1.2" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F030102 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 701 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index 11000000 | VLEN = 12 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.12" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060A2B06010201041F03010c ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleDataSet_2indices"/> shows the Data Records that export the values of the
3 mibObjectValue Information Elements.
</t>
<figure align="center" anchor="figure_ExampleDataSet_2indices"
title="Example of an MIB Data Set for an Indexed MIB Object with two indices.">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 701 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipVer = 1 | ifIndex = 10 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InForwDatagrams = 10000 | ipVer = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex = 10 | InForwDatagrams = 20000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- Indexed MIB Object with two OIDs -->
<!-- PJ: this is section 6.5: -->
<section anchor="sectionUseCasePSAMPwithanIPFIXInformationElement"
title="Exporting a Columnar Object indexed by IEs: ifOutQLen">
<t>
If a PSAMP Packet Report <xref target="RFC5476"/> was generated on any dropped
packets on an interface then it may be desirable to know if the send queue on
the output interface was full. This could be done by exporting the size of the
send queue (ifOutQLen) in the same Data Record as the PSAMP Packet Report.
</t>
<t>
The exported data looks like:
</t>
<texttable anchor="PSAMP_Data"
title="Packet Report with Interface Output Queue Length (ifOutQLen) Data">
<ttcol align="center">SRC ADDR</ttcol>
<ttcol align="center">DST ADDR</ttcol>
<ttcol align="center">PAK LEN</ttcol>
<ttcol align="center">OUTPUT INTERFACE</ttcol>
<ttcol align="center">OUTPUT Q. LEN (ifOutQLen)</ttcol>
<c>192.0.2.1</c> <c>192.0.2.3</c> <c>150</c> <c>Eth 1/0 (15)</c> <c>45</c>
<c>192.0.2.4</c> <c>192.0.2.9</c> <c>350</c> <c>Eth 1/0 (15)</c> <c>45</c>
<c>192.0.2.3</c> <c>192.0.2.9</c> <c>650</c> <c>Eth 1/0 (15)</c> <c>23</c>
<c>192.0.2.4</c> <c>192.0.2.6</c> <c>350</c> <c>Eth 1/1 (16)</c> <c> 0</c>
</texttable>
<t>
The ifOutQLen MIB object defined in the IF-MIB <xref target="RFC2863"/> provides
the length of the output packet queue. This columnar object is
part of the ifEntry conceptual row and indexed by the interface index (ifIndex).
</t>
<t>This relationship between the ifOutQLen field and the index field is exported using mibIndexIndicator in
the MIB Field Options Template. The value of "00010000" flags the index fields concisely.
</t>
<t>
The Template Record for the example Data Record contains the following Information Elements:
</t>
<t>
<list hangIndent="2" style="numbers">
<t>
sourceIPv4Address
</t><t>
destinationIPv4Address
</t><t>
totalLengthIPv4
</t><t>
egressInterface
</t><t>
ifOutQLen indexed by: egressInterface
</t>
</list>
</t>
<t>
<xref target="figure_ExampleTemplateSet_PSAMP"/> shows the exported Template
Set detailing the Template for exporting a PSAMP Report with Interface Output
Queue Length (ifOutQLen).
<xref target="figure_mibFieldOptionTemplate_PSAMP"/> and <xref target="figure_mibFieldOptionData_PSAMP"/>
show the MIB Field Options Template and Data Record.</t>
<figure align="center" anchor="figure_ExampleTemplateSet_PSAMP"
title="Example of Template for a PSAMP Report with ifOutQLen indexed by egressInterface">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 703 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = totalLengthIPv4 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = egressInterface | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_mibFieldOptionTemplate_PSAMP"
title="Example of MIB Field Options Template for a PSAMP Report with ifOutQLen indexed by egressInterface">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 704 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_mibFieldOptionData_PSAMP"
title="Example of MIB Field Options Data Record for a PSAMP Report with ifOutQLen indexed by egressInterface">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 704 | Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 703 | informationElementIndex = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00010000 | VLEN = 11 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.2.2.1.21" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06092B0601020102020115 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
The corresponding IPFIX Data Record is shown in <xref target="figure_ExampleDataSet_PSAMPPacketReport_withIPFIXIE"/>.
For the sake of the example, the interface index of "Eth 1/0" is 15 and the
interface index of "Eth 1/1" is 16.
</t>
<figure align="center" anchor="figure_ExampleDataSet_PSAMPPacketReport_withIPFIXIE"
title="Example of PSAMP Packet Report with ifOutQLen indexed by egressInterface">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 703 | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 650 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 (Eth 1/0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 350 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 (Eth 1/1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- Indexed MIB Objects with one IPFIX IE: Output Interface Queue Size in PSAMP Packet Report -->
<section anchor="sectionUseCaseContext"
title="Exporting With Multiple Contexts: The OSPF Neighbor Row Revisited">
<t>If the Context used to export the MIB objects is the default one no extra context fields are required. This example demonstrates
how to handle the case when the Context needs to be specified. It is based on the previous example <xref target="sectionUseCaseSequence"/>.
</t>
<t>The OSPF details exported of the conceptual row in <xref target="sectionUseCaseSequence"/> would be suitable if there were
only one OSPF process running at the Observation Point. If multiple OSPF processes are present then they can be differentiated by also
exporting the mibContextEngineID and mibContextName.
</t>
<t>The following fields will be exported:</t>
<texttable anchor="ospfNbrEntryObjectsContext" title="OSPF Neighbor Entry Objects">
<ttcol align="left">Object</ttcol>
<ttcol align="left">ID</ttcol>
<ttcol align="left">mibObjectValue</ttcol>
<ttcol align="center">Len</ttcol>
<c>ospfNbrIpAddr </c><c>ospfNbrEntry 1</c> <c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrAddress- </c><c>ospfNbrEntry 2</c> <c>mibObjectValueInteger </c><c>4</c>
<c>-LessIndex </c><c/><c/><c/>
<c>ospfNbrRtrId </c><c>ospfNbrEntry 3</c> <c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrState </c><c>ospfNbrEntry 6</c> <c>mibObjectValueInteger </c><c>1</c>
</texttable>
<t>
The example contextEngineID matches the example from <xref target="RFC3411"/> for Acme Networks:
"'800002b804616263'H (enterprise 696, string 'abc')"
</t>
<t>
<xref target="figure_Example_Templates_ospfNbrEntry_context"/> shows the Templates Exported to support a mibObjectValueRow that is defined within a context.
<xref target="figure_Example_OIDData_ospfNbrEntry_context"/> shows the example OID Data for the conceptual row exported in mibObjectValueRow. These are unchanged from the previous example.
<xref target="figure_Example_Data_ospfNbrEntry_context"/> shows the example data for 2 OSPF neighbors. Although these have identical INDEX/scope values the context information indicates they come from different OSPF processes.
Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long.
</t>
<figure align="center" anchor="figure_Example_Templates_ospfNbrEntry_context"
title="Example of ospfNbrEntry Template and Options Template Sets with Context">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 800 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibContextEngineID | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibContextName | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueRow | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 801 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueIPAddress|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 22 | Template ID = 802 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 3 | Scope Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = templateId | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = informationElementIndex| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectIdentifier | Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 803 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibSubIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_OIDData_ospfNbrEntry_context"
title="Example of ospfNbrEntry OID Data export with Context">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 800 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06082B060102010E0A01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 803 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 801 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 1 | templateId = 801 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 1 | mibSubIdentifier = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 801 | informationElementIndex = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibSubIdentifier = 3 | templateId = 801 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 3 | mibSubIdentifier = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_Example_Data_ospfNbrEntry_context"
title="Example of Data Export for ospfNbrEntry with Context">
<artwork align="center">
<![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 800 | Length = 60 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextEngineID = 800002b804616263 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibContextEngineID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextName = con1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 801 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextEngineID = 800002b804616263 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibContextEngineID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibContextName = con2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Semantic=0xFF | Template ID = 801 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrIpAddr = 192.0.2.1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrAddressLessIndex = 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
</section> <!-- Use Cases -->
<!-- PJ: this is section 7: -->
<section anchor="sectionConfConsiderations" title="Configuration Considerations">
<t>
When configuring a MIB OID for export, consideration should be given to whether the SNMP Context String should also be configurable.
If a non-default Context String is used then it should be associated with the fields as per <xref target="sectionIdentifyingContext"/>.
</t>
</section>
<!-- PJ: this is section 8: -->
<section anchor="sectionCollectingProcess" title="The Collecting Process's Side">
<t>
The specifications in section 9 of <xref target="RFC7011"/> also apply to Collectors that implement this specification.
In addition, the following specifications should be noted.
</t>
<t>
A Collecting Process that implements this specification MUST store the data records containing the OID Object Type Definitions
with the same retention policy as templates.
</t>
<t>
A Collecting Process that implements this specification SHOULD have access to
MIB modules in order to look up the received MIB Object Identifiers and find
the full type definition and name of MIB OID fields used in received templates.
</t><t>
It should be noted that since reduced size encoding MAY be used by the Exporting Process,
the Collecting Process cannot assume a received size for a field is the maximum
size it should expect for that field. </t>
<t>
If a Collecting Process receives a MIB Object Identifier that it cannot decode, it MAY log a warning.
</t>
<t>
A Collecting Process MUST support the 3 options for handling columnar objects detailed in
<xref target="sectionExportingSequences"/>.
</t>
</section> <!-- The Collecting Process's Side -->
<!-- PJ: this is section 9: -->
<section anchor="sectionApplicability" title="Applicability">
<t>
Making available the many and varied items from MIB modules opens up a wide range of possible applications for the IPFIX protocol, some quite different from the usual flow information.
</t>
<t>
Some monitoring applications periodically export an interface ID to interface name mapping using IPFIX Options Templates. This could be expanded to include the MIB object "ifInUcastPkts" of the IF-MIB <xref target="RFC2863"/> indexed using the ingressInterface Information Element. This would give the input statistics for each interface which can be compared to the flow information to ensure the sampling rate is expected. Or, if there is no sampling, to ensure that all the expected packets are being monitored.
</t>
</section> <!-- Applicability -->
<!-- PJ: this is section 10: -->
<section anchor="sectionSecurity" title="Security Considerations">
<t>
For this extension to the IPFIX protocol, the same security
considerations as for the IPFIX protocol apply
<xref target="RFC7011"/>.
</t>
<t>If the exporter is generating or capturing the field values itself, e.g., using the MIB objects only as an encoding or type mechanism,
there are no extra security considerations beyond standard IPFIX.</t>
<t>However, if the exporter is implemented as an SNMP manager accessing an SNMP agent,
it MUST authenticate itself to the SNMP agent
<xref target="RFC3414"/>,
<xref target="RFC5591"/>,
<xref target="RFC5592"/>,
<xref target="RFC6353"/>,
and the SNMP agent MUST enforce SNMP access control rules
<xref target="RFC3415"/>
as required by the SNMP architecture
<xref target="RFC3411"/>.
</t><t>
The access to particular MIB objects is controlled by the configuration
of the IPFIX exporter. This is consistent with the way IPFIX
controls access to other Information Elements in general.
</t><t>
The configuration of an IPFIX Exporter determines which MIB
objects are included in IPFIX Data Records sent to certain
collectors. Network operators should take care that the only MIB
objects which are included in IPFIX Data Records are ones which the receiving
flow collector is allowed to receive.
Note that multiple users may have access to the data from the flow collector.
</t><t>
When exporting MIB objects that may be considered sensitive or vulnerable in some network environments
(as mentioned in the Security Considerations section of the RFC containing the MIB module),
the Exporter should consider using "IP Flow Anonymization Support" <xref target="RFC6235"/> if the information is anonymizable.
Consumers of exported data should therefore be able to handle the kinds of modifications to data described in <xref target="RFC6235"/>.
</t>
</section> <!-- Security Considerations -->
<!-- PJ: this is section 11: -->
<section anchor="sectionIANA" title="IANA Considerations">
<section anchor="newIPFIXsemantics" title="New IPFIX Semantics">
<t>
New IPFIX semantics must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/> per section 6 of <xref target="RFC7012"/>,
as defined in the sub-sections below.
</t>
<section anchor="snmpCounter" title="snmpCounter">
<t>
An integral value reporting the value of a counter,
identical to the Counter32 and Counter64 semantics in <xref target="RFC2578"/>,
as determined by the field length.
</t>
<t>
This is similar to IPFIX's totalCounter semantic,
except that total counters have an initial value of 0,
while SNMP counters do not.
</t>
</section>
<section anchor="snmpGauge" title="snmpGauge">
<t>
An integral value identical to the Gauge32 semantic in <xref target="RFC2578"/>,
and the Gauge64 semantic in <xref target="RFC2856"/>,
as determined by the field length.
</t>
</section>
</section>
<!-- PJ: this is section 11.1: -->
<section anchor="sectionIANANewInformationElements" title="New IPFIX Information Elements">
<t>
The new Information Elements in <xref target="New_Information_Elements"/>
must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, as defined in the sub-sections below.
</t>
<t>
In each case the "Units" and "Range" are to be left blank, since these are not applicable.
</t>
<texttable anchor="New_Information_Elements" title="New Information Elements">
<ttcol align="left">ElementId</ttcol>
<ttcol align="left">Name</ttcol>
<c>TBD1</c><c>mibObjectValueInteger</c>
<c>TBD2</c><c>mibObjectValueOctetString</c>
<c>TBD3</c><c>mibObjectValueOID</c>
<c>TBD4</c><c>mibObjectValueBits</c>
<c>TBD5</c><c>mibObjectValueIPAddress</c>
<c>TBD6</c><c>mibObjectValueCounter</c>
<c>TBD7</c><c>mibObjectValueGauge</c>
<c>TBD8</c><c>mibObjectValueTimeTicks</c>
<c>TBD9</c><c>mibObjectValueUnsigned</c>
<c>TBD10</c><c>mibObjectValueTable</c>
<c>TBD11</c><c>mibObjectValueRow</c>
<c>TBD12</c><c>mibObjectIdentifier</c>
<c>TBD13</c><c>mibSubIdentifier</c>
<c>TBD14</c><c>mibIndexIndicator</c>
<c>TBD15</c><c>mibCaptureTimeSemantics</c>
<c>TBD16</c><c>mibContextEngineID</c>
<c>TBD17</c><c>mibContextName</c>
<c>TBD18</c><c>mibObjectName</c>
<c>TBD19</c><c>mibObjectDescription</c>
<c>TBD20</c><c>mibObjectSyntax</c>
<c>TBD21</c><c>mibModuleName</c>
</texttable>
<section anchor="sectionIANANewElementsValues" title="New MIB Value Information Elements">
<section anchor="mibObjectValueIntegerIE" title="mibObjectValueInteger">
<t>
A new Information Element "mibObjectValueInteger" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that the integer value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of Integer32 and INTEGER with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type of signed64.
</t>
<t>
Abstract Data Type: signed64
</t>
<t>
Data Type Semantics: identifier
</t>
<t>
ElementId: TBD1
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueOctetStringIE" title="mibObjectValueOctetString">
<t>
A new Information Element "mibObjectValueOctetString" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that an Octet String or Opaque value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of OCTET STRING and Opaque.
The value is encoded as per the standard IPFIX Abstract Data Type of octetArray.
</t>
<t>
Abstract Data Type: octetArray
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD2
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueOIDIE" title="mibObjectValueOID">
<t>
A new Information Element "mibObjectValueOID" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty"> <t>
Description:
An IPFIX Information Element which denotes that an Object Identifier or OID value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of OBJECT IDENTIFIER.
Note - In this case the "mibObjectIdentifier" will define which MIB object is being exported while the value contained
in this Information Element will be an OID as a value.
The mibObjectValueOID Information Element is encoded as ASN.1/BER <xref target="BER"/> in an octetArray.
</t>
<t>
Abstract Data Type: octetArray
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD3
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueBitsIE" title="mibObjectValueBits">
<t>
A new Information Element "mibObjectValueBits" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that a set of Enumerated flags or bits from a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of BITS.
The flags or bits are encoded as per the standard IPFIX Abstract Data Type of octetArray,
with sufficient length to accommodate the required number of bits.
If the number of bits is not an integer multiple of octets
then the most significant bits at end of the octetArray MUST be set to zero.
</t>
<t>
Abstract Data Type: octetArray
</t>
<t>
Data Type Semantics: flags
</t>
<t>
ElementId: TBD4
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueIPAddressIE" title="mibObjectValueIPAddress">
<t>
A new Information Element "mibObjectValueIPAddress" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that the IPv4 Address of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of IPaddress.
The value is encoded as per the standard IPFIX Abstract Data Type of ipv4Address.
</t>
<t>
Abstract Data Type: ipv4Address
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD5
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueCounterIE" title="mibObjectValueCounter">
<t>
A new Information Element "mibObjectValueCounter" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that the counter value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of Counter32 or Counter64 with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64.
</t>
<t>
Abstract Data Type: unsigned64
</t>
<t>
Data Type Semantics: snmpCounter
</t>
<t>
ElementId: TBD6
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueGaugeIE" title="mibObjectValueGauge">
<t>
A new Information Element "mibObjectValueGauge" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that the Gauge value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of Gauge32.
The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64.
This value will represent a non-negative integer, which may increase or decrease, but shall never exceed a maximum value,
nor fall below a minimum value.
</t>
<t>
Abstract Data Type: unsigned32
</t>
<t>
Data Type Semantics: snmpGauge
</t>
<t>
ElementId: TBD7
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueTimeIE" title="mibObjectValueTimeTicks">
<t>
A new Information Element "mibObjectValueTimeTicks" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that the TimeTicks value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of TimeTicks.
The value is encoded as per the standard IPFIX Abstract Data Type of unsigned32.
</t>
<t>
Abstract Data Type: unsigned32
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD8
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueUnsignedIE" title="mibObjectValueUnsigned">
<t>
A new Information Element "mibObjectValueUnsigned" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that an unsigned integer value of a MIB object will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with the Base Syntax of unsigned64 with IPFIX Reduced Size Encoding used as required.
The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64.
</t>
<t>
Abstract Data Type: unsigned64
</t>
<t>
Data Type Semantics: identifier
</t>
<t>
ElementId: TBD9
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueTableIE" title="mibObjectValueTable">
<t>
A new Information Element "mibObjectValueTable" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that a complete or partial conceptual table will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with a SYNTAX of SEQUENCE.
This is encoded as a subTemplateList of mibObjectValue Information Elements.
The template specified in the subTemplateList MUST be an Options Template and MUST include all the Objects listed in the INDEX clause as Scope Fields.
</t>
<t>
Abstract Data Type: subTemplateList
</t>
<t>
Data Type Semantics: list
</t>
<t>
ElementId: TBD10
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueRowIE" title="mibObjectValueRow">
<t>
A new Information Element "mibObjectValueRow" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that a single row of a conceptual table will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This Information Element is used for MIB objects with a SYNTAX of SEQUENCE.
This is encoded as a subTemplateList of mibObjectValue Information Elements.
The subTemplateList exported MUST contain exactly one row (i.e., one instance of the subtemplate).
The template specified in the subTemplateList MUST be an Options Template and MUST include all the Objects listed in the INDEX clause as Scope Fields.
</t>
<t>
Abstract Data Type: subTemplateList
</t>
<t>
Data Type Semantics: list
</t>
<t>
ElementId: TBD11
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- values -->
<!-- PJ: this is section 11.2: -->
<section anchor="sectionIANANewElementsMIBFieldOption" title="New MIB Field Options Information Elements">
<section anchor="mibObjectIdentifierIE" title="mibObjectIdentifier">
<t>
A new Information Element "mibObjectIdentifier" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
An IPFIX Information Element which denotes that a MIB Object Identifier (MIB OID) is exported in the
(Options) Template Record.
The mibObjectIdentifier Information Element contains the OID assigned to the MIB Object Type Definition encoded as ASN.1/BER <xref target="BER"/>
</t>
<t>
Abstract Data Type: octetArray
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD12
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibSubIdentifierIE" title="mibSubIdentifier">
<t>
A new Information Element "mibSubIdentifier" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
A non-negative sub-identifier of an Object Identifier (OID).
</t>
<t>
Abstract Data Type: unsigned32
</t>
<t>
Data Type Semantics: identifier
</t>
<t>
ElementId: TBD13
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibIndexIndicatorIE" title="mibIndexIndicator">
<t>
A new Information Element "mibIndexIndicator" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
This set of bit fields is used for marking the Information
Elements of a Data Record that serve as INDEX MIB objects for an indexed Columnar MIB object.
Each bit represents an Information Element in the Data Record with the
n-th bit representing the n-th Information Element. A bit set
to value 1 indicates that the corresponding Information
Element is an index of the Columnar Object represented by the mibFieldValue.
A bit set to value 0 indicates that this is not the case.
</t>
<t>
If the Data Record contains more than 64 Information
Elements, the corresponding Template SHOULD be designed such
that all INDEX Fields are among the first 64 Information
Elements, because the mibIndexIndicator only contains 64 bits.
If the Data Record contains less than 64 Information
Elements, then the extra bits in the mibIndexIndicator for which no
corresponding Information Element exists MUST have the value 0,
and must be disregarded by the Collector.
This Information Element may be exported with IPFIX Reduced Size Encoding.
</t>
<t>
Abstract Data Type: unsigned64
</t>
<t>
Data Type Semantics: flags
</t>
<t>
ElementId: TBD14
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibCaptureTimeSemanticsIE" title="mibCaptureTimeSemantics">
<t>
A new Information Element "mibCaptureTimeSemantics" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
Indicates when in the lifetime of the flow the MIB value was retrieved from the MIB for a mibObjectIdentifier.
This is used to indicate if the value exported was collected from the MIB closer to flow creation or flow export
time and will refer to the Timestamp fields included in the same record.
This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics.
</t>
<t>
If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value
(i.e., the data is already stale) and it's important to know the exact sampling time,
then an additional observationTime* element should be paired with the OID using structured data.
Similarly, if different mibCaptureTimeSemantics apply to different mibObject elements within the Data Record,
then individual mibCaptureTimeSemantics should be paired with each OID using structured data.
</t>
<t>
Values:
<list style="none">
<t>0. undefined</t>
<t>1. begin - The value for the MIB object is captured from the MIB when the Flow is first observed</t>
<t>2. end - The value for the MIB object is captured from the MIB when the Flow ends</t>
<t>3. export - The value for the MIB object is captured from the MIB at export time</t>
<t>4. average - The value for the MIB object is an average of multiple captures from the MIB over the observed life of the Flow</t>
</list>
</t>
<t>
Abstract Data Type: unsigned8
</t>
<t>
Data Type Semantics: identifier
</t>
<t>
ElementId: TBD15
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibContextEngineIDIE" title="mibContextEngineID">
<t>
A new Information Element "mibContextEngineID" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
A mibContextEngineID that specifies the SNMP engine ID for
a MIB field being exported over IPFIX. Definition as per <xref target="RFC3411"/> section 3.3
</t>
<t>
Abstract Data Type: octetArray
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD16
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibContextNameIE" title="mibContextName">
<t>
A new Information Element "mibContextName" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
This Information Element denotes that a MIB Context Name is specified for a MIB field being exported
over IPFIX.
Reference <xref target="RFC3411"/> section 3.3
</t>
<t>
Abstract Data Type: string
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD17
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- end MIB Field Options Fields -->
<!-- PJ: this is section 11.3: -->
<section anchor="sectionIANANewElementsMIBTypeOption" title="New MIB Type Information Elements">
<section anchor="mibObjectNameIE" title="mibObjectName">
<t>
A new Information Element "mibObjectName" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
The name (called a descriptor in <xref target="RFC2578"/>) of an object type definition.
</t>
<t>
Abstract Data Type: string
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD18
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectDescriptionIE" title="mibObjectDescription">
<t>
A new Information Element "mibObjectDescription" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
The value of the DESCRIPTION clause of an MIB object type definition.
</t>
<t>
Abstract Data Type: string
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD19
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectSyntaxIE" title="mibObjectSyntax">
<t>
A new Information Element "mibObjectSyntax" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
The value of the SYNTAX clause of an MIB object type definition,
which may include a Textual Convention or Subtyping.
See <xref target="RFC2578"/>.
</t>
<t>
Abstract Data Type: string
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD20
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibModuleName" title="mibModuleName">
<t>
A new Information Element "mibModuleName" must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, with the following definition:
<list hangIndent="5" style="empty">
<t>
Description:
The textual name of the MIB module that defines a MIB Object.
</t>
<t>
Abstract Data Type: string
</t>
<t>
Data Type Semantics: default
</t>
<t>
ElementId: TBD21
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- end mibType fields -->
</section> <!-- New Info Elements -->
</section> <!-- IANA Considerations -->
<!-- PJ: this is section 12: -->
<section title="Acknowledgements">
<t>The authors would like to thank Andrew Johnson for his collaboration on
the first version of the draft, and to thank Andrew Feren and Brian Trammell
for their detailed reviews.</t>
<t>
Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!--
There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).
-->
<references title="Normative References">
<!--
The references below are defined at the top of this file. If you
want to add a reference you MUST add it at the top.
-->
&RFC2119;
&RFC2578;
&RFC2856;
&RFC3411;
&RFC6526;
&RFC7011;
&RFC7012;
<reference anchor="IANA-IPFIX"
target="http://www.iana.org/assignments/ipfix/ipfix.xml">
<front>
<title>IPFIX Information Elements registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA-IPFIX-SDTS"
target="http://www.iana.org/assignments/ipfix/ipfix.xml">
<front>
<title>IPFIX Structured Data Types Semantics registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="BER"
target="http://www.iso.org">
<front>
<title>Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1),International
Organization for Standardization. International Standard
8825, December 1987</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<!-- The references below are defined at the top of this file. If
you want to add a reference you MUST add it at the top. -->
&RFC2863;
&RFC2982;
&RFC3414;
&RFC3415;
&RFC3444;
&RFC4022;
&RFC4293;
&RFC4750;
&RFC4960;
&RFC5470;
&RFC5476;
&RFC5591;
&RFC5592;
&RFC6235;
&RFC6313;
&RFC6353;
<reference anchor="CISCO-PROCESS-MIB"
target="http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&mibName=CISCO-PROCESS-MIB">
<front>
<title>CISCO-PROCESS-MIB.my: MIB for CPU and process statistics</title>
<author fullname="Ramanathan R. Kavasseri">
<organization>Cisco Systems Inc.</organization>
</author>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:16:49 |