One document matched: draft-ietf-ipfix-mib-variable-export-04.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 RFC2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.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">
-->
<!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">
<!ENTITY RFC2981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2981.xml">
<!ENTITY RFC2982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2982.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.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 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 RFC6313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6313.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.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-04"
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>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>96 Commercial Quay</street>
<street>Commercial Street</street>
<city>Edinburgh</city>
<region></region>
<code>EH6 6LX</code>
<country>UK</country>
</postal>
<phone>+44 131 561 3616</phone>
<email>paitken@cisco.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" 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>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>96 Commercial Quay</street>
<street>Commercial Street</street>
<city>Edinburgh</city>
<region></region>
<code>EH6 6LX</code>
<country>UK</country>
</postal>
<phone>+44 131 561 3634</phone>
<email>cmcdowal@cisco.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="2014"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>IPFIX Working Group</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 Option Template and method are specified, which are used to
export the extra information required to fully describe
Simple Network Management Protocol (SNMP) MIB Objects.
</t>
</abstract>
</front>
<middle>
<!-- PJ: this is section 1: -->
<section anchor="sectionOpenIssues" title="Open Issues / To do list">
<t>
<list style="symbols">
<t>
"timestamps, exporters, and other animals" -> see the mailing list.
</t>
<!--
The issue is to provide a timestamp indicating when the OID was sampled.
1. Could this be prior to the IPFIX exporter requesting the value? (ie the data was already stale.) If so, this is a harder problem to solve since the timestamp must come from the SNMP infra which provides the OID (ie, in the form "value X as at time T").
Else, if it's reasonable for the exporter indicating the time at which the OID was retrieved from the SNMP infra - so, not taking into account how fresh or how stale the data may be - then the existing IPFIX observationTime* elements can readily be used.
2. Is a single timestamp sufficient for all OIDs, or are individual timestamps required per OID? In the latter case, how to express the timestamp / OID relationship? Perhaps IPFIX structured data.
3. If there are other timestamps in the flow record - eg, flowStart* / flowEnd* - then was the OID observed at the start or end time, or another time?
Considering 2+3, I would say something like, "if timestamps are required, an observationTime* element should be paired with the OID using structured data."
-->
<!-- CM: Not a problem now - any index is another field in the ipfix template and can have any
size or variable size. Each subidentifier will still be limitted to 32bits however.
<t>
The value of the MIB OID acting as an index may not be of fixed length
and may have no default length,
for example the OID can be of type string or type MIB OID.
</t>
-->
<t>
Some TODOs in the XML version:
<list style="symbols">
<t>
write section 6.7: "Indexed MIB Objects with a mix of MIB OID and IPFIX Information Element"
</t>
<t>
write section 6.10: "Using MIB Objects with IPFIX Structured Data"
</t>
<t>
write section 6.11: "Using IPFIX Structured Data to group the index MIB and indices"
</t>
</list>
</t>
<t>
RFC 5610: explain what needs to be updated.
</t>
<t>
ID to name mappings? -> use this for an example in section 5.
</t>
<t>
What does this mean? : "(Consider the counter synchronization issue, non-key info should be static)".
</t>
<!-- CM - done
<t>
(JS) Do we need to add something about the contextEngineID and contextName?
Optionally associate context with template via options
Could be done with common properties or in a flow record. See section 5.6.
However, do we limit all MIB variables in a Template Record to a single context?
3 cases:
<list hangIndent="2" style="numbers">
<t>
if a simple SNMP agent, no contextEngineID and contextName, because it's the default
</t>
<t>
the context information is valid for the entire flow record
</t>
<t>
the context information is specific for each IE within the entire flow record
</t>
</list>
question regarding 3.: only one context for an entire flow or can a flow record export MIB OID from different context?
(JS): ask the IPFIX mailing list.
(BC): ask internally in Cisco
Action: complete the "Identifying the SNMP Context" section
</t>
-->
<t>
(JS) Inacio's figure: send email to the mailing list.
</t>
<t>
Tidy up the XML.
</t>
<t>
Add missing examples in sections 6.7, 6.9.1, 6.9.2, 6.10, 6.11.
</t>
<t>
Describe all the orphaned figures ("Figure NN shows ...").
</t>
<t>
Add example which uses mibContextEngineID and mibContextName.
</t>
<t>Clear up figure 6/7 or surrounding text - "I have trouble to understand Figure 6 and Figure 7." js</t>
<t>
"I am confused by Figure 14(-03 draft) with a "Set ID = ??" Is this left
from the earlier version?" - AF
</t>
<t>
Make clear ordering constraints or lack of
"What about ordering requirements? I assume no lexicographic ordering needed when MIB data is moved via IPFIX?" - JS
</t>
<t> "In the enumeration in section 5.2 (-03 draft), I suggest to inline the explanations rather than having the explanation below." - JS
</t>
<t>Generalise the enterprise specific example, then probably remove the example:
"Is section 6.3 really needed? The only important sentence is this: This example stresses that, even though the OID cpmCPUTotal1minRev is enterprise-specific, the E bit for the mibObjectValue and mibObjectIdentifier is set to "0" since the "mibObjectValue" and "mibObjectIdentifier" Information Element is not enterprise-specific. This should be generalized and written down where the normative text is of the mibObjectValue and mibObjectIdentifier definitions, e.g. The E bit of the mibObjectValue or mibObjectIdentifier Information Elements is set to "0" since they are not enterprise-specific. This holds true even if the data carried inside the mibObjectValue or mibObjectIdentifier may be enterprise specific.H18" - JS
</t>
<t>
"Should ipIfStatsIPVersion not be InetVersion in Figure 24?" - JS
</t>
<t>"Is Figure 22(-03 draft) a "Options Template Set"? I expected this to be a Template Set" - JS</t>
<t>"Am I correct that the example in 6.4 (-03 draft) is supposed to show the value
of ipIfStatsInForwDatagrams (10000 and 20000) for ip4 and ip6
on interface 10? If so, note that InetVersion encodes IPv4
using '1' and IPv6 using '2'. In any case, showing how a data
record is encoded is very useful but requires some textual
explanation." - JS</t>
<t>"Why do we talk about IPFIX transports in section 8(-03 draft)? All this should be pretty agnostic to the choice of the transport, no?" - JS</t>
<t>Clear up relationship to SNMP - Ie Accessing MIB not accessing via / through SNMP.</t>
<t>"I think there needs to be some more explicit text saying that the
security administrator must make sure that IPFIX export of MIB
objects does not cause a hole into the SNMP access control
configuration. (Some SNMP hardliners might even say that IPFIX
should access data through the SNMP access control subsystem,
in which case there would need to be proper parameters such as
a (securityName, securityModel, securityLevel) tuple..." -
JS</t>
<t>Check all uses of 'OID' for correctness - "Section 11.2 says "the
MIB OID" which is ambiguous at best. It should probably be "the
OID of a MIB object" or even better "the OID assigned to the
MIB object definition"." - JS</t>
<t>Spell out 1-1 mapping of fields to mibFieldOptions: "Figure 4 helps
getting an overview (but perhaps a bit late). But you seem to
make the assumption that there is a fixed # of mibObjectValues
mapping to the same fixed number of mibFieldOptions. This may
be fine - I am just noting this (and if correct it might be
good to spell it out)."</t>
<t>Add note about 7011 Section 8
"Options Templates and Templates that are related or interdependent
(e.g., by sharing common properties as described in [RFC5473]) SHOULD
be sent together in the same IPFIX Message" - CMCD
</t>
</list> <!-- End of TODO list. Add items
here! -->
</t>
</section>
<!-- 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="RFC7012"
/>, 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 seperate
system of definitions. There are no dependencies between the SMIv2 <xref target="RFC2578"/>
and the SNMP protocol. This opens up the possibility to 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>
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>mibObjectValue<> IEs</t>
<t>mibFieldOption IEs</t>
<t>mibTypeInformation IEs</t>
</list>
</t>
<t>
This document also defines some standard Option Templates that are used
as part of the mechanism to export MIB Object meta data.
<list style="symbols">
<t>mibFieldOption</t>
<t>mibSequenceOption</t>
<t>mibTypeOption</t>
</list>
</t>
<t>
This document specifies a method for creating an IPFIX Option Template
which is used to export the extra data required
to describe MIB variables (see <xref target="requiredMinimum"/>).
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-indexed or indexed MIB object(s).
Enterprise-specific MIB Object Identifiers are also supported.
</t>
<figure align="center" anchor="figure_overview_field"
title="Architectural Overview">
<artwork align="center">
<![CDATA[
+------------------------+
| mibFieldOptionTemplate |
+------------------------+
|
V
+---------------------+ +------------------------+
| Data Template | | mibFieldOption |
| mibObjectValue<>IEs |<----| OIDs |
+---------------------+ +------------------------+
|
V
+--------------------+
| Data Flows |
| MIB Object Values |
+--------------------+]]>
</artwork>
</figure>
<t>
One common type defined in the SMIv2 are SEQUENCEs or
conceptual tables. It is desirable that exporting a complete
or partial SEQUENCE is simple and efficient. This is accomplished
by having a alternative option export that can export only the
OID of the sequence as a whole.
</t>
<figure align="center" anchor="figure_overview_sequence"
title="Architectural Overview Sequence">
<artwork align="center">
<![CDATA[
+---------------------------+
| mibSequenceOptionTemplate |
+---------------------------+
|
V
+------------------------+
+---------------------+ | mibSequenceOption |
| Data Template |<----| single OID |
| mibObjectValue<>IEs | +------------------------+
+---------------------+
|
V
+--------------------+
| Data Flows |
| MIB Sequence Rows |
+--------------------+]]>
</artwork>
</figure>
<t>
When individual MIB columner objects are exported, a method to
identify how that MIB object is indexed is specified so that
the full meaning of the information being exported can be
conveyed. The specification encompasses the different index types
for the MIB Object Identifier:
<list style="symbols">
<t>indexed by one or multiple MIB variable(s)</t>
<t>indexed by one or multiple IPFIX Information Element(s)</t>
<t>indexed by a mix of MIB variable(s) and IPFIX Information Element(s)</t>
<t>indexed by a string</t>
</list>
A set of example use cases illustrates how these specifications can be
used.
</t>
<t>
Some Exporters may not have the knowledge to convey the full information on
how the MIB objects being exported are indexed. They may not know the index
count and/or the OIDs of the objects that are used to index a MIB object.
In such cases the Exporter can send the the values of the index OIDs
identifying the instance of the object being exported as one string that
conveys the instance identifier part of an object being exported. The
Collecting Process may know how a MIB object is indexed by some other means,
for example, it could compile this information from the MIB Module that
defines exported MIB object or the Collecting Process could be hardcoded with
this information for a pre-defined set of MIB objects that it is
interested in. An example use case is used to illustrate this mechanism.
</t>
</section>
<!-- PJ: this is section 3: -->
<section anchor="sectionMotivation" title="Motivation and Architectural Model">
<t>
Most Flow Records contain the ingressInterface and/or the
egressInterface Information Element. 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
Flow 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 and SNMP
polling engine, SNMP data is retrieved shortly after Data
Records have been received, which implies the sum of the
active or inactive timeouts (if not null) plus the time to
export the Flow 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 significant.
</t>
</list>
</t>
<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. More specifically, the
case of an existing Template Record, which needs to be augmented
with some MIB variables whose index was already present in the
Template Record as an IPFIX Information Element: typically, a 7-tuple Record
containing the ingressInterface Information Element, augmented by interface counters
<xref target="RFC2863"/>, which are indexed by the respective
ingressInterface values in the Data Records.
</t>
<t>
The intended goal of this work is not a replacement of SNMP
notifications, even if the specifications in this document could
potentially allow this. 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 a new textual conventions, can be
exported within IPFIX and then decoded in the Collector.
</t>
<figure align="center" anchor="figure_arch"
title="Architectural Model">
<artwork align="center">
+------+ +-------+ +.........+ +.....+
| SNMP | | IPFIX | : NETCONF : : CLI :
+------+ +-------+ +.........+ +.....+
| | | |
+--------------------------------------------+
| Instrumentation (specified in MIB modules) |
+--------------------------------------------+
</artwork>
</figure>
<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>
</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, Flow 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" as this specification allows the export
of MIB objects.
</t>
<t>MIB Object Identifier (MIB OID)
<list hangIndent="5" style="empty">
<t>
An ASCII character sequence of decimal non-negative
sub-identifier values. Each sub-identifier value MUST NOT
exceed 2^32-1 (4294967295) and MUST NOT have leading
zeros. Sub-identifiers are separated by single dots and
without any intermediate whitespace.
</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.
</t>
</list>
</t>
<t>mibObjectValue<>
<list hangIndent="5" style="empty">
<t>Refers to any and all of the mibObjectValue IEs generically.
Any restriction or requirment in this document that refers to mibObjectValue<>
applies to the following IEs: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS,
mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime, mibObjectValueUnsigned,
mibObjectValueTable andmibObjectValueSequence.
<!-- make this a sublist? -->
</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 -->
<!-- PJ: this is section 5: -->
<section anchor="sectionMibObject" title="MIB Object Value Information Element and the MIB Field Option Template ">
<t>
This document defines new mibObjectValue<> Information Elements (in <xref target="sectionIANA"/>).
These are used to export MIB Objects as part of standard IPFIX Templates.
The mibObjectValue<> Information Elements contains the actual data values retrieved from a MIB Object.
</t>
<t>
The issue that arises from exporting MIBs in IPFIX is that the standard IPFIX
Template format (<xref target="RFC7011"/>) only provides the Collector with the length of the Information Element.
The actual MIB OID would be unknown, so every MIB Field would appear identical and the contents of the MIB field
would be incomprehensible data to a Collector.
</t>
<t>
For the values in the mibObjectValue<> fields to be understandable, more meta information about the mibObjectValue<>
must be sent as part of the IPFIX export. The required minimum to undertand 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 newer set versions.
</t>
<t>
This document defines a mibFieldOption Template to export the extra meta information required for a mibObjectValue<> field.
This is a standard IPFIX Option Template Set that MUST include 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<> fields.
</t>
<!-- PJ: this is section 5.1: -->
<section anchor="sectionMIBFieldOptionFormat" title="MIB Field Option Template Format">
<t>
For each mibObjectValue<> field that is defined in an IPFIX Data or Option Template, a
mibFieldOption Data Record MUST be exported that provides the required minimum
information to define the MIB object that is being exported (see <xref target="requiredMinimum"/>).
This mibFieldOption is defined in a template referred to in this document as a mibFieldOption Template
and has the format that is specified in <xref target="sectionFormats"/>.
</t>
<t>
A Template that uses a mibObjectValue<> Field MUST be exported in the same IPFIX message as the corresponding
mibFieldOption Template and Data Records. Note that this places an implicit size constraint on the export.
</t>
<!-- CM: this is section 5.1.1: -->
<section anchor="sectionMIBFieldOptionOrdering" title="Use of field order in the MIB Field Option template">
<t>
The mibFieldOption export makes use of the informationElementIndex to specify which
field in the template that the metadata relates to, which avoids any
ordering constraints on the data template. The MIB field and any fields used to
index it can be in any order in the export packet.
</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
mibfieldOption data MUST be resent to reflect the new ordering. A new Template
id MUST be used to reflect that the ordering has changed. Otherwise older
mibFieldOption details may be used to refer to the incorrect field.
</t>
</section> <!-- Use of field order-->
<section anchor="requiredMinimum" title="Minimum Required MIB Object Fields">
<t>
To unambiguously export a mibObjectValue<> Field 3 fields are REQUIRED:
<list style="symbols">
<t>(scope) templateId</t>
<t>(scope) informationElementIndex</t>
<t>mibObjectIdentifier (<xref target="mibObjectIdentifierIE"/>)</t>
</list>
These are the minumum fields required in a mibFieldOptionTemplate <xref target="sectionFormatMIBFieldOptionTemplate"/>.
</t>
<t>
While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as they are per field.
<list style="symbols">
<t>mibCaptureTimeSemantics (<xref target="mibCaptureTimeSemanticsIE"/>)</t>
<t>mibIndexIndicator (<xref target="mibIndexIndicatorIE"/>)</t>
<t>mibContextEngineID (<xref target="mibContextEngineIDIE"/>)</t>
<t>mibContextName (<xref target="mibContextNameIE"/>)</t>
</list>
</t>
<t>
There are also fields that provide type information from a MIB Object definition that MAY be exported to a CP.
Since these values are statically defined in the MIB they are not expected to change frequently.
However the additional information about the MIB may help a CP that does not have access to the MIB.
<list style="symbols">
<t>mibObjectName (<xref target="mibObjectNameIE"/>)</t>
<t>mibObjectDescription (<xref target="mibObjectDescriptionIE"/>)</t>
<t>mibObjectSyntax (<xref target="mibObjectSyntaxIE"/>)</t>
<t>mibModuleName (<xref target="mibModuleName"/>).</t>
</list>
</t>
</section>
</section> <!-- MIB Field Option -->
<!-- PJ: this is section 5.2: -->
<section anchor="sectionMIBFieldOptionArchitecture" title="MIB Field Option Architecture">
<t>
Four IPFIX Sets are used together to export a Flow using the mibObjectValue<> Field.
These are:
</t>
<t>
<list style="numbers">
<t>A Data or Option Template Set which includes the mibObjectValue<> field.</t>
<t>A mibFieldOption Template Set</t>
<t>mibFieldOption Data Set</t>
<t>Data Set.</t>
</list>
</t>
<t>
The Template Set or Option Template Set informs the Collector that a MIB Object Value of length n will be exported.
</t><t>
The mibFieldOption Template describes which metadata will be sent for each mibObjectValue<> being exported.
</t><t>
The mibFieldOption Data Set includes the metadata for each MIB object (ie the mibObjectIdentifier).
The metadata about the mibObjectValue<>s only needs to be resent as per normal Template refreshes or resends.
</t><t>
The Data Set contains only the actual data extracted from the MIB.
</t><t>
<xref target="figure_mibFieldOptionIpfixMessage"/> shows the IPFIX Message structure for a MIB Field in a Template Set, while
<xref target="figure_mibFieldOptionIpfixMessageOption"/> shows the IPFIX Message structure for a MIB Field in an Option 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) |
+----------------------------------------------------+
| Option Template Set (B) (mibFieldOption Template) |
+----------------------------------------------------+
| Data Set (B) (mibFieldOption Data) |
+----------------------------------------------------+
| Data Set (A) |
+----------------------------------------------------+]]>
</artwork>
</figure>
<t>The mibFieldOption Template can be used with Standard Option Templates as well.</t>
<figure align="center" anchor="figure_mibFieldOptionIpfixMessageOption"
title="IPFIX Message structure for a MIB Field in an Option Template Set">
<artwork align="center">
<![CDATA[+----------------------------------------------------+
| IPFIX Message Header |
+----------------------------------------------------+
| Option Template Set (C) |
+----------------------------------------------------+
| Option Template Set (B) (mibFieldOption Template) |
+----------------------------------------------------+
| Data Set (B) (mibFieldOption Data) |
+----------------------------------------------------+
| Data Set (C) |
+----------------------------------------------------+]]>
</artwork>
</figure>
<t>More Data Sets that use the mibObjectValue<> can then be send in subsequent packets.</t>
<t><xref target="figure_RecordRelationshipDiagram"/> shows the relationships
between the Records discussed above.
</t><t>
The mibFieldOption Template defines mibFieldOption Records.
The mibFieldOption Data record annotate the Data Template with mibObjectValue<> metadata.
Together the Data Template and mibFieldOption define the Data Records that will be exported.
</t>
<t>
The Data Records X have a dependency on the 2 Templates and the mibFieldOption Data Records.
</t>
<figure align="center" anchor="figure_RecordRelationshipDiagram"
title="Relationships between Sets">
<artwork align="center">
<![CDATA[ +--------------------------+
|mibFieldOption Template(B)|
+--------------------------+
|(templateId, elementIndex)|
+--------------------------+
| mibOID |
+--------------------------+
|
| Defines
V
+------------------------+ +--------------------------+
| Data Template (X) | | mibFieldOption Data (B) |
+------------------------+ +--------------------------+
|Field 0 - regular IE | | |
+------------------------+ +--------------------------+
|Field 1-mibObjectValue<>| <----------- | (X,1) = OID |
+------------------------+ Annotates +--------------------------+
|Field 2-mibObjectValue<>| <----------- | (X,2) = OID |
+------------------------+ +--------------------------+
| |
|------------------------------------/
|
| Defines
|
V
+------------------------+
| Data Records (X) |
|------------------------|
| Field 0 data |
+------------------------+
| Field 1 data |
+------------------------+
| Field 2 data |
+------------------------+]]>
</artwork>
</figure>
</section> <!-- Architecture -->
<!-- CM: this is section 5.3: -->
<section anchor="sectionFormats" title="MIB Field Option 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 the mibObjectValue<> field is identical to the standard
IPFIX Format as defined in <xref target="RFC7011"/>, so the mibObjectValue<> field is specified using standard IPFIX Field Specifiers as
in <xref target="RFC7011"/>.
</t>
<t>
The only extra requirement on a Template Record using mibObjectValue<> Fields is that it MUST export the required metadata specified
for EACH mibObjectValue<> Field (see <xref target="requiredMinimum"/>). Multiple mibFieldOption MUST NOT be exported that refer
to a single mibObjectValue<>.
</t>
<t>
There is a one to one mapping between each mibObjectValue<> field and a mibFieldOption.
</t>
<t>
A mibFieldOption 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<> Field.
</t>
<figure align="center" anchor="figure_FormatDataTemplate"
title="IPFIX Template Set using mibObjectValue<> 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 = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = Existing IPFIX Field | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|IE=mibObjectValueInteger TBD1| Field Length (mib) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>Where:
<list hangIndent="2" style="empty">
<t>mibObjectValueInteger
<list hangIndent="3" style="empty">
<t>
One of the mibObjectValue<> IPFIX Information Elements that denotes that a
MIB Object data (ie, the value of a MIB OID)
will be exported in the (Options) Template Record.
The specific type of the data in this case would be an Integer.
Any other mibObjectValuee<> could be used to export a different MIB object type.
When a mibObjectValue<> Information Element is used, the MIB Object Identifier ("mibObjectIdentifier")
MUST be exported via a mibFieldOption 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 OID 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="sectionFormatOptionTemplate" title="Option Template containing a MIBObject Field">
<t>
The Option Template Record Format of a Template that uses the mibObjectValue<> field is identical to the standard
Format as defined in <xref target="RFC7011"/>. The mibObjectValue<> field is specified using standard Field Specifiers as
in <xref target="RFC7011"/>.
</t>
<t>
A mibObjectValue<> Field can be a Scope Field or a Non Scope Option Field.
</t>
<t>
The only extra requirement on a Option Template Record using mibObjectValue<> Fields is that it MUST export the required metadata specified
in <xref target="requiredMinimum"/> for EACH mibObjectValue<> Field.
</t>
<t>
An IPFIX Option Template Record MUST export a mibFieldOption Template and Data Record to provide the minimum required
metadata for each mibObjectValue<> Field.
</t>
<figure align="center" anchor="figure_FormatOptionTemplateNonScope"
title="IPFIX Option 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0|IE=mibObjectValueInteger TBD1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_FormatObjectTemplateScope"
title="IPFIX Option 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0|IE=mibObjectValueInteger TBD1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |0| IE = Existing IPFIX Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section>
<!-- CM: this is section 5.3.2: -->
<section anchor="sectionFormatMIBFieldOptionTemplate" title="mibFieldOption Template">
<t>
The mibFieldOption Template is a Standard Option Template which defines the Fields that
will be exported to provide enough metadata about a mibObjectValue<> so that the Collector
can tie the data values in the mibObjectValue<> back to the definition of the MIB Object.
</t>
<t>All mibFieldOption Templates MUST contain the following Fields:
<list hangIndent="5" style="symbols">
<t>(scope) templateId</t>
<t>(scope) informationElementIndex</t>
<t>mibObjectIdentifier</t>
</list>
</t>
<t>A mibFieldOption Template MAY specify other Information Elements as part of the mibFieldOption
template.</t>
<t>This document defines some common optional Information Elements which allow exporting more information about
MIB Indexing, extra data from the MIB and the semantics of how the mibObjectValue<> was collected prior to export.
See <xref target="sectionIANANewElements"/>.
</t>
<figure align="center" anchor="figure_mibFieldOptionTemplate"
title="MIB Field Option 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 mibFieldOption Data Record. This Template Identifier paired with an index into
that template, the "informationElementIndex" field, uniquely references one mibObjectValue<> Field 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 will uniquely reference one
mibObjectValue<> Field 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<> exported in the (Options) Template Record.
</t><t>
When the MIB Object Value Information Element is used,
the MIB Object Identifier MUST be specified in the mibFieldOption 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 mibFieldOption Template.
</t>
</list>
</t>
</list>
</t>
</section>
<!-- CM: this is section 5.3.4: -->
<section anchor="sectionFormatMIBFieldDataRecords" title="mibFieldOption Data Records">
<t> The mibFieldOption Data Records conform to the Template Specification in the mibFieldOption Template.
There may be multiple mibFieldOption Records exported.</t>
<t>The Collecting Process MUST store all received mibFieldOption Data
information for the duration of each Transport Session, because the Collecting Process will need to refer to the
extra meta information to decode a mibObjectValue<> Field fully.
</t>
<t>
<xref target="figure_FormatMibFieldOptionDataRecord"/> shows the format of the exported mib Field Option
detailing the metadata that will be exported to match the Template in section (see <xref target="figure_mibFieldOptionTemplate"/>).
</t>
<figure align="center" anchor="figure_FormatMibFieldOptionDataRecord"
title="Format of mibFieldOption 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.5: -->
<section anchor="sectionFormatMIBFieldOptionTemplateIndexed" title="mibFieldOption Template with Indexing">
<figure align="center" anchor="mibFieldOptionTemplateIndexed"
title="mibFieldOption Format for a indexed MIB 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope field count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = informationElementIndex|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Where:
<list hangIndent="2" style="empty">
<t>mibIndexIndicator
<list hangIndent="3" style="empty">
<t>
The MIB Index List 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 mibObjectIdentifier to completely index the value.
</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 SEQUENCE they belong to.
</t>
<t>
The Information Elements referred to by
mibIndexIndicator could be any Information
Element(s) that can be
appended onto a the mibObjectIdentifier to index it fully.
</t><t>
See '7.7. Mapping of the INDEX clause'<xref target="RFC2578"/> for which MIB Objects will be suitable
for INDEXing a Sequence and how they are appended to the fully index an OID.
</t><t>
If there are no other suitable Fields to index a
mibObjectValue<>, then one or more mibSubIdentifier field can be
included in the (Options) Template Record and refered to by the mibIndexIndicator.
This allows the implementer some flexiblility to export a MIB values with a simple IE that will
always be an option.
</t>
</list>
</t>
</list>
</t>
</section> <!-- Indexed Template -->
<!-- CM: this is section 5.3.6: -->
<section anchor="sectionFormatMIBFieldOptionTemplateSemantics" title="mibFieldOption Template with Semantics Fields">
<t>A mibFieldOption Template MAY specify that extra Information Elements will be exported
to record how the mibObjectValue<> was collected</t>
<figure align="center" anchor="mibFieldOptionTemplateSemantics"
title="mibFieldOption Format 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>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 mibObjectValue<>s that specify 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.7: -->
<section anchor="sectionFormatMIBFieldOptionTemplateObjectDetails" title="mibFieldOption Template with extra MIB Object Details">
<t>The MIB OID exported within the mibObjectIdentifier IPFIX Information Element provides a reference
to a MIB that will fully describe the MIB Variable being Exported.</t>
<t>However an Exported Process MAY decide to include some extra MIB Fields to more fully describe the
mibObjectValue<>.</t>
<t>This can be helpful if the Collecting Process may not have access to the MIB. It also allows the IPFIX Field Types to
be extended with any MIB Variable already defined purely through IPFIX.</t>
<t>The exporting process can either include the extra Object Details fields as part of the mibFieldOption Template or
export a separate Option Template and Data that maps MIB OIDs in mibObjectIdentifier Fields to the Object details.</t>
<t>If a single or few fields are being exported then including extra type data in the mibFieldOption export will be more
efficient.
</t>
<figure align="center" anchor="mibFieldOptionTemplateObjectDetails"
title="mibFieldOption Format for a non-indexed Field 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>mibOjectSyntax
<list hangIndent="3" style="empty">
<t>
The MIB SYNTAX clause string for a mibObjectIdentifier, which contains the SYNTAX string
as defined for the MIB Object referenced by the MIB OID.
This will either be the name of one of the primitive "base types" from <xref target="RFC2578"/> or
a Textual Convention name.
</t><t>
The SYNTAX clause may also include subtyping or specific enumerations for known values or flags.
</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 which defines a MIB OID Object.
</t>
</list>
</t>
</list>
</t>
<t>Or the MIB details can be exported as an Standard Option Export as shown in <xref target="mibOidDetailsOption"/></t>
<t>This may be more efficent as the bulk of this data is text based and SHOULD be exported once to the CP if there are many
MIB objects being exported. This prevents this large textual data being included for every use of a mibObjectValue<> field.
</t>
<figure align="center" anchor="mibOidDetailsOption"
title="Alternative Option Export mibObjectIdentifier to 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 -->
<!-- PJ: this was section 5.4: -->
<!-- PJ: TODO: the below is all redundant now. -->
<!--
<section anchor="indicesConsiderations" title="Indices Considerations">
<t>
When using an Indexed MIB object, the Template Record contains the index/indices length.
In some cases, this index/indices information might be redundant in the export information.
For example, when the index is an Information Element already contained in the Template Record,
the length is already part of the Template Record, and available to the Collecting Process
for decode, as shown in the example in
<xref target="sectionUseCasePSAMPwithanIPFIXInformationElement"/>.
A second example in <xref target="sectionUsingScope"/> is when a specific MIB OID
is already part of the Template Record as a standalone MIB object in a Template Record,
and also reused as an index.
</t>
<t>
However, there are two cases where the index length is required.
Therefore, for consistent decoding by the Collecting Process,
the Index Length is always specified next to the index.
</t>
<t>
Situation 1: When a non-indexed MIB object is used as an index,
and doesn't appear as a standalone MIB object in the Template Record,
the Collecting Process might not want, per design,
to access the MIB modules in order to find the length of the value for a particular MIB OID.
</t>
<t>
Situation 2: A Template Record might contain two similar Information Elements
with different encoding lengths (even if this situation is an unlikely real-world scenario),
while an Indexed MIB Object might want to refer to one of this Information Elements
as the index. However, without clearly specifying the index length, the Collecting
Process would not know which length to decode the index with.
</t>
<t>
When an Information Element is used as index, there MUST be one and only one
similar Information Element with the exact same length in the Template Record,
so that the Collecting Process knows which Information Element value
from the Flow Records to match. Note that this rule also implies that
the reduced size encoding <xref target="RFC7011"/> of the Information Element
in the index compared to the Information Element in the Template Record
is not allowed. If the Collecting Process can not determine clearly
which Information Element value to chose as the index because there are two (or more)
Information Elements with the same length, then index MUST specified as the
MIB Object Identifier.
</t>
<t>
An indexed MIB object MAY be indexed by a mix of MIB OID(s) and IPFIX Information Element(s).
</t>
</section> --><!-- Indices Considerations-->
</section> <!-- sectionFormats -->
<!-- PJ: this is section 5.4: -->
<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
MIB context MUST be identified by including the mibContextEngineID (<xref target="mibContextEngineIDIE"/>)
and mibContextName (<xref target="mibContextNameIE"/>) fields in the mibFieldOption Template and
associated mibFieldOption data records.
</t>
<t>
This context data must be included for each field that is not in the default context.
</t>
<t>
TODO - example with contexts
</t>
<t>
See <xref target="sectionIANA"/>.
</t>
</section> <!-- Identifying the SNMP Context -->
<!-- PJ: this is section 5.5: -->
<section anchor="sectionTemplateManagement" title="Template Management">
<t>
Templates are managed as per <xref target="RFC7011"/> with the additional constraint
that the mibFieldOption Template and Data Records MUST be exported in the same IPFIX Message
as any (Option) Template Record that uses a mibObjectValue<>.
</t> <t>
If a Template using mibObjectValue<>s 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 Record then a new mibFieldOption Data Record
MUST be sent with the replacement referencing the new Template ID.
</t><t>
An Exporting Process SHOULD reuse mibFieldOption Template IDs IFF the Templates are identical. Each
(Option) Template Record MUST still be accompanied by a copy of the mibFieldOption Template.
</t>
</section> <!-- Template Management -->
<!-- CM: this is section 5.6: -->
<section anchor="sectionDataModel" title="IPFIX and MIB Data Model">
<t>The RFC 2578 species that the SYNTAX clause for a MIB Object defines the abstract data structure
of an Object and 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)."
<xref target="RFC2578"/> section-7.1
</t>
<t>For each of these the options this draft specifies exactly which mibObjectValue<> to use.</t>
<!--TODO COLIN - flow chart ? -->
<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 mibOjectSyntax IE SHOULD be used to export this detail to the CP.</t>
<t>The Options for the SYNTAX are then mapped as follows:</t>
<texttable anchor="dataModelTable" title="SMIv2 SYNTAX -> mibObjectValue types">
<ttcol align="left">RFC2578 Section No</ttcol>
<ttcol align="left">SYNTAX</ttcol>
<ttcol align="left">mibObjectValue<></ttcol>
<c>7.1.1 </c><c> Integer32 and INTEGER </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> mibObjectValueTime</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> Conceptual Tables </c><c> mibObjectValueTable or mibObjectValueSequence</c>
</texttable>
<t>Values are encoded as per the standard IPFIX encoding of Abstract Data Types. The only new encoding references in this document is that Object
Identifiers (OID) will be encoded as per ASN.1/BER <xref target="BER"/> in an octetArray</t>
</section>
<!-- CM: this is section 5.7: -->
<section anchor="sectionExportingSequences" title="Exporting Sequences">
<t>
There are several approaches for an IPFIX exporting process to use MIB SEQUENCES also known as conceptual tables.
</t>
<t>
<list hangIndent="5" style="empty">
<t>A columnar object may be used purely use as a data type. In this case no indexing or relation to a sequence provided by
the exporting process.</t>
<t>As part of an option export of the contained and complete conceptual table. A SEQUENCE OF</t>
<t>In a mixed option/data IPFIX/MIB template where the mib value can be indexed by other fields in the record</t>
<t>Using structured data to export the complete "SEQUENCE OF" or individual rows of "SEQUENCE"s
As part of a mibObjectValueSequence structured data export</t>
</list>
</t>
<t>This draft defines two forms of Indexing that can be used for SEQUENCE MIB Objects</t>
<t>FIELD based indexing is used by having every mibObjectValue<> export a mibIndexIndicator to flag the Index fields required.
This allows complex indexing or mixing of existing IPFIX IE with MIB Fields. It also allows multiple MIB SEQUENCE values to be exported
with complete indexing in 1 IPFIX Template.</t>
<t>SEQUENCE based Indexing is used by having a single Option Export that corresponds to the SEQUENCE or conceptual table. Each SEQUENCE of the
MIB Object corresponds to a single Flow Record. The Index Fields defined in the INDEX clause of the MIB Object MUST all be present
the same order as the Scope fields. This allows a simple table export of a MIB SEQUENCE without any extra indexing fields. There is a 1-to-1
mapping between the SEQUENCE and the option export so only the OID for the SEQUENCE must be exported.</t>
<t>Using structured data for Sequence export allows complete SEQUENCE 'conceptual rows' or SEQUENCE OF 'conceptual tables' to be exported
completely as a single field in a record. The structured data fields mibObjectValueTable and mibObjectValueSequence always use
SEQUENCE based Indexing</t>
<section anchor="sectionExportingSequencesComplete" title="Exporting Sequences - Complete">
<t>
Exporting a complete MIB Sequence is done with an IPFIX Option Template Set. All the scope fields for the option record are used as the index
fields. The mibIndexIndicator is not required in the mibFieldOption record.
</t>
<t>
When mibSequenceOption indexing of a sequence is used all scope fields MUST be the INDEX Objects in the same order as defined in the MIB SEQUENCE being exported.
</t>
<t>Any extra INDEX fields that are part of the SEQUENCE MUST be included in the scope fields of the template if they occur in the INDEX clause before any field in
the row. If the INDEX fields are not the initial MIB Objects in the sequence or are not in the same order in the INDEX and the SEQUENCE then mibSequenceOption
MUST not be used and the complete information for the table MUST be exported using individual mibFieldOption records and mibIndexIndicator fields.
</t><t>The mibObjectValue<> fields exported using the mibSequenceOption Sequence export MUST all be members of the same SEQUENCE Object.
</t>
<figure align="center" anchor="figure_mibSequenceOptionTemplate"
title="IPFIX Option Template for a complete SEQUENCE 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = Z | 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="mibSequenceOptionTemplateIndexed"
title="mibSequenceOption Format for a SEQUENCE 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope field count = 2 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 SEQUENCE that is being exported with this mibSequenceOption.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="sectionExportingSequencesStructuredData" title="Exporting Sequences - Structured Data">
<t>
TODO.
see mibObjectValueTable and mibObjectValueSequence.
</t>
</section>
<section anchor="sectionExportingSequencesExplicit" title="Exporting Sequences - Explicit">
<t>
The other option for indexing a sequence is explicit indexing. In this case
there may be non index fields in the scope of the option export or there may be
multiple mib objects being exported with different indexes. In this case each
mib field requires the mibIndexIndicator with the bits set for the fields that
are used to index that individual Object. The index fields MUST be in the 'correct' order as
defined in the SEQUENCE that the columnar object is a member of.
</t>
<t>
See section <xref target="sectionFormatMIBFieldOptionTemplateIndexed"/>.
TODO merge these sections together.
</t>
</section>
</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-indexed 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="RFC7012"/>, 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 (see <xref target="sectionUseCaseTcpCurrEstab"/>).
</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 = 257 | 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 Option
detailing the metadata that will be exported about the mibObjectValueGauge Field in Template 257 in Template Record (see <xref target="sectionUseCaseTcpCurrEstab"/>).
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionTemplateSet_tcpCurrEstab"
title="Example of tcpCurrEstab mibFieldOption 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 = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionDataSet_tcpCurrEstab"/> shows the exported mib Field Option
detailing the metadata that will be exported about the mibObjectValueGauge Field in Template 257 in Template Record (see <xref target="sectionUseCaseTcpCurrEstab"/>).
</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. This will take 9 bytes.
</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionDataSet_tcpCurrEstab"
title="Example of tcpCurrEstab mibFieldOption 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 = 258 | Length = 25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 257 | informationElementIndex = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=9 | mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... MIB Object Idenfier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>
</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 = 257 | 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, a non-indexed
MIB object is chosen for simplicity. The CPU Usage of a remote network device
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. 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="RFC7012"/>, 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 = 53 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 259 | 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 mibfieldOption Template Record for exporting CPU Load (see <xref target="sectionUseCaseCpuLoad"/>).
Note this identical to the mibFieldOption 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 mibFieldOption Template Set ">
<artwork align="center">
<![CDATA[ 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 260 | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleMibFieldOptionDataSet_CPULoad"/> shows the exported mib Field Option
detailing the metadata that will be exported about the mibObjectValueGauge Field in Template 259 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 bytes long.</t>
<figure align="center" anchor="figure_ExampleMibFieldOptionDataSet_CPULoad"
title="Example of CPULoad mibFieldOption 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 = 260 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 259 | 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 encoded it within a single octet.
</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 Complete Sequence Table: The OSPF Neighbor Sequence">
<t>Many conceptual tables are already defined in standard and proprietary MIBs. These can be exported
with a minimum of overhead by using the mibSequenceOption. This allows the exporter to unambiguously define
an export of an entie sequence as an Option Export. The use of mibSequenceOption means that each individual
columnar object does not need to have it's OID exported to the collector</t>
<t>The ospfNbrTable defined in TODO OSPF MIB is a Sequence Of ospfNbrEntry, which has the OID "1.3.6.1.2.1.14.10.1".
Each option 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">mibObjectValue</ttcol>
<ttcol align="center">Length in bytes</ttcol>
<c>ospfNbrIpAddr </c><c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrAddressLessIndex </c><c>mibObjectValueInteger </c><c>4</c>
<c>ospfNbrRtrId </c><c>mibObjectValueIPAddress</c><c>4</c>
<c>ospfNbrOptions </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrPriority </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrState </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrEvents </c><c>mibObjectValueCounter </c><c>4</c>
<c>ospfNbrLSRetransQLen </c><c>mibObjectValueGauge </c><c>4</c>
<c>ospfNBMANbrStatus </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbmaNbrPermanence </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrHelloSuppressed </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrRestartHelperStatus </c><c>mibObjectValueInteger </c><c>1</c>
<c>ospfNbrRestartHelperAge </c><c>mibObjectValueUnsigned </c><c>4</c>
<c>ospfNbrRestartHelperExitReason </c><c>mibObjectValueInteger </c><c>1</c>
</texttable>
<figure align="center" anchor="figure_ExampleOptionTemplate_ospfNbrEntry"
title="Example of ospfNbarEntry 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 = 66 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 300 | Field Count = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueGauge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| IE = mibObjectValueUnsigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| IE = mibObjectValueInteger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_ExampleMibSequenceOptionTemplateSet_ospfNbrEntry"
title="Example of ospfNbarEntry Sequence mibSequenceOption Template Set ">
<artwork align="center">
<![CDATA[ 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 301 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope field count = 1 |0| IE = templateId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibIndexIndicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| IE = mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_ExampleMibSequenceOptionDataSet_ospfNbrEntry"
title="Example of ospfNbarEntry mibSequenceOption 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 = 301 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 300 | Index 1100000000000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN=17 | mibObjectIdentifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.14.10.1" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 060f2b8006800180028001800e800a8001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>TODO - Generate some data for this example</t>
</section>
<!-- PJ: this is section 6.4: -->
<section anchor="sectionUseCaseSequenceSelectedObject"
title="Exporting Selected Objects Sequence : The ipIfStatsInForwDatagrams">
<t>It may be that the full set of columnar objects that are supported by a SEQUENCE are
not required to be exported. In this case the Objects specified by the INDEX clause of the
SEQUENCE MUST be exported in the correct order and refered to by the mibIndexListIE included
in the mibFieldOption Template.
</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 SEQUENCE. This is comprised
of ipIfStatsEntry conceptual rows.
</t>
<t>
The ipIfStatsTable SEQUENCE is indexed by the ipIfStatsIPVersion and ipIfStatsIfIndex, therefore to export ipIfStatsInForwDatagrams
clearly they should be included.</t>
<t>Since textual conventions are being used the SYNTAX is also being exported as part of the mibFieldOption</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) <!-- CM - ipIfStatsIPVersion -->
</t>
<t>
ipIfStatsIfIndex (1.3.6.1.2.1.4.31.3.1.2) (scope field) <!-- CM InterfaceIndex -->
</t>
<t>
ipIfStatsInForwDatagrams (1.3.6.1.2.1.4.31.3.1.12) (non-scope field)
</t>
</list>
</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 = 261 | 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 mibFieldOptions Template used to export
the required mibObjectValue<> metadata. This example of the mibFieldOption Template includes the mibIndexList 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 = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 262 | 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 mibFieldOption Data used to export
the required mibObjectValue<> metadata. Note that the first 2 Data Records have their mibIndexIndicator length set to an empty
length of 0. The third mibIndexIndicator has the value '11000000' to show that the first 2 fields in the record are the
Index's for this columnar object.
</t>
<!-- for lengths - 1.3.6.1.2.1.4.31.3.1.1 = 06132b80068001800280018004801f800380018001 len = 21 -->
<!-- for lengths - 1.3.6.1.2.1.4.31.3.1.2 = 06132b80068001800280018004801f800380018002 len = 21 -->
<!-- for lengths - 1.3.6.1.2.1.4.31.3.1.12 = 06132b80068001800280018004801f80038001800c len = 21 -->
<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 = 262 | Length = 140 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 261 | informationElementIndex = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00000000 | VLEN = 21 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.1" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06132b80068001800280018004801f800380018001 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | templateid 261|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... templateid | informationElementIndex = 1 |Index 00000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLEN = 21 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.4.31.3.1.2" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06132b80068001800280018004801f800380018002 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | templateId = 261 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| informationElementIndex = 2 |Index 11000000 | OID VLEN = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mibObjectIdentifier "1.3.6.1.2.1.4.31.3.1.12" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06132b80068001800280018004801f80038001800c ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<xref target="figure_ExampleDataSet_2indices"/> shows the Data records that export the values of the
3 mibObjectValue<>.
</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 = 261 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 10 | 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | 20000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- Indexed MIB Object with two OIDs-->
<!-- PJ: this is section 6.5: -->
<section anchor="sectionUseCasePSAMPwithanIPFIXInformationElement"
title="Indexed MIB Object with an IPFIX Information Element: Output Interface Queue Size in PSAMP Packet Report">
<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 be 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 I/F</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 MIB object for the Interface Output Queue Length, ifOutQLen
("1.3.6.1.2.1.2.2.1.21"), this is part of the ifEntry SEQUENCE that has as it's index ifIndex interface index as detailed
in the IF-MIB <xref target="RFC2863"/>. If, for example, the interface index
of "Eth 1/0" in the example is 15, the full MIB Object Identifier for
(ifOutQLen) would be "1.3.6.1.2.1.2.2.1.21.15".</t>
<t>This relationship between the ifOutQLen field and the index field is exported using mibIndexIndicator in
the mibFieldOption. The value of "00010000" flags the index fields concisely.
</t>
<t>
In fact, only how the indexed object was indexed is necessary, although it is
often useful to specify the index value. The example identifies the Egress
Interface, but for other uses it may be sufficient to know that the ifOutQLen
value was taken for the interface that the packet was switched out of, without
identifying the actual interface. </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 mibFieldOption 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 = 63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 263 | 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 mibFieldOption 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 = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 264 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>
<!-- ASN for 1.3.6.1.2.1.2.2.1.21 = 06112b80068001800280018002800280018015 len 19 -->
<figure align="center" anchor="figure_mibFieldOptionData_PSAMP"
title="Example of mibFieldOption 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 = 264 | Length = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 263 | informationElementIndex = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00010000 | VLEN = 19 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.2.2.1.21" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06112b80068001800280018002800280018015 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+]]>
</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 = 260 | 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 -->
<!-- PJ: this is section 6.6: -->
<section anchor="sectionUseCasePSAMPwithanOID"
title="Indexed MIB Object with an OID: Output Interface Queue Size in PSAMP Packet Report">
<t>
Following on the example from the previous section (see <xref target="sectionUseCasePSAMPwithanIPFIXInformationElement"/>), if the Template
Record for the example Data Record does not contain the egressInterface, the
ifOutQLen can be indexed by the ifIndex interface index as detailed in the
IF-MIB <xref target="RFC2863" /> by including as many mibSubIdentifier as are required.</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>
ifOutQLen indexed by: the mibSubIdentifier
</t><t>
mibSubIdentifier
</t>
</list>
</t>
<t>Note the only significant difference between this and the previous example is that by using the mibSubIdentifier the exporter is
exposing less information about the type of the Index.</t>
<t>
<xref target="figure_ExampleTemplateSet_PSAMP_string_index"/> shows the exported Template Set detailing the Template for exporting a PSAMP Report with Interface Output Queue Length (ifOutQLen) but using the ifIndex MIB object as the exported index.</t>
<figure align="center" anchor="figure_ExampleTemplateSet_PSAMP_string_index"
title="Example of Template for a PSAMP Report with ifOutQLen indexed by a string index">
<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 = 63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 265 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = sourceIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = destinationIPv4Address | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = totalLengthIPv4 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibObjectValueGauge | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| IE = mibSubIdentifier | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<figure align="center" anchor="figure_mibFieldOptionTemplate_PSAMP_string_index"
title="Example of mibFieldOption Template for a PSAMP Report with ifOutQLen indexed by a string index">
<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 = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 266 | 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_string_index"
title="Example of mibFieldOption Data Record for a PSAMP Report with ifOutQLen indexed by a string index">
<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 = 266 | Length = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| templateId = 265 | informationElementIndex = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index 00001000 | VLEN = 19 | mibObjectIdentifier ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "1.3.6.1.2.1.2.2.1.21" ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 06112b80068001800280018002800280018015 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
Note that IPFIX reduced size encoding <xref target="RFC7011"/> has been used in this example to express ifOutQLen in a single octet, rather than the 32 bits specified in the IF-MIB <xref target="RFC2863" />.
</t>
<t>
The corresponding IPFIX Data Record is shown in <xref target="figure_ExampleDataSet_PSAMPPacketReport_withOID"/>.
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_withOID"
title="Example of PSAMP Packet Report with the ifOutQLen using ifIndex from IF-MIB [RFC2863] as an index">
<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 = 263 | Length = 72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 45 | 15 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 192.0.2.4 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 192.0.2.9 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 350 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 45 | 15 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 192.0.2.3 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 192.0.2.9 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 650 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 23 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 15 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 192.0.2.4 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 192.0.2.6 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 350 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</section> <!-- Indexed MIB Objects with one MIB variable: Output Interface Queue Size in PSAMP Packet Report -->
</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>
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process specifically related to TCP or UDP transport protocols are specified in section 10 of <xref target="RFC7011"/>.
</t>
<t>
The specifications in section 9 of <xref target="RFC7011"/> also apply to Collector's that implement this specification. In addition, the following specifications should be noted.
</t>
<t>
A Collecting Process that implements this specification MUST have access to MIB modules in order to look up the received MIB Object Identifiers and find the type and name of MIB OID fields used in received templates. 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 SHOULD log an error.
</t>
<t>
If a Collecting Process receives a MIB Object Identifier for an indexed MIB object but isn't sent the appropriate number of indices then it SHOULD log an error, but it MAY use the Template Record to decode the Data Records as the associated indices are purely semantic information.
</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. Some potential enhancements for traditional applications are detailed below:
</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, as a index. 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>
The access to 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. 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.
</t>
</section> <!-- Security Considerations -->
<!-- PJ: this is section 11: -->
<section anchor="sectionIANA" title="IANA Considerations">
<section anchor="sectionIANANewElements" title="New Information Elements">
<t>
The following new Information Elements must be allocated in IANA's IPFIX registry
<xref target="IANA-IPFIX"/>, as defined in the following sub-sections:
<list style="symbols">
<t>mibObjectValueInteger</t>
<t>mibObjectValueOctetString</t>
<t>mibObjectValueOID</t>
<t>mibObjectValueBITS</t>
<t>mibObjectValueIPAddress</t>
<t>mibObjectValueCounter</t>
<t>mibObjectValueGauge</t>
<t>mibObjectValueTime</t>
<t>mibObjectValueUnsigned</t>
<t>mibObjectValueTable</t>
<t>mibObjectValueSequence</t>
<t>mibSubIdentifier</t>
<t>mibObjectIdentifier</t>
<t>mibIndexIndicator</t>
<t>mibCaptureTimeSemantics</t>
<t>mibContextEngineID</t>
<t>mibContextName</t>
<t>mibObjectName</t>
<t>mibObjectDescription</t>
<t>mibObjectSyntax</t>
<t>mibModuleName</t>
</list>
</t>
<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 an integer value from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with the Base Syntax of Integer32 and INTEGER with RLE 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: default
</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 from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE 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>
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 from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE 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 IE 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>
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 will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with the Base Syntax of BITS.
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: 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 an IPv4 Address Object from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE 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>
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 a counter value from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with the Base Syntax of Counter32 or Counter64 with RLE 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: totalCounter
</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 a Gauge value from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE 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 minum value.
</t>
<t>
Abstract Data Type: unsigned32
</t>
<t>
Data Type Semantics: totalCounter
</t>
<t>
ElementId: TBD7
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueTimeIE" title="mibObjectValueTime">
<t>
A new Information Element "mibObjectValueTime" 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 TimeTicks value from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with the Base Syntax of TimeTicks.
The value is encoded as per the standard IPFIX Abstract Data Type of dateTimeMilliseconds.
</t>
<t>
Abstract Data Type: dateTimeMilliseconds
</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 from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with the Base Syntax of unsigned64 with RLE 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>
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 MIB 'SEQUENCE OF X' or conceptual table value from a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with a SYNTAX of SEQUENCE OF.
This is encoded as a basicList of "mibObjectValueSequence"s. The mibObjectValueSequence MUST be of the same type/OID as specified
in this MIB Object's syntax.
</t>
<t>
Abstract Data Type: basicList
</t>
<t>
ElementId: TBD10
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
<section anchor="mibObjectValueSequenceIE" title="mibObjectValueSequence">
<t>
A new Information Element "mibObjectValueSequence" 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 SEQUENCE or a row from a conceptual table value as defined in a MIB will be exported.
The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means.
This IE is used for MIB Objects with a SYNTAX of SEQUENCE.
This is encoded as a templateList of mibObjectValue<> IEs.
The template specified in MUST be an Option Template and MUST include all the Objects listed in the INDEX clause as Scope fields.
</t>
<t>
Abstract Data Type: templateList
</t>
<t>
ElementId: TBD11
</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. One Sub number from an Object Identifier (OID).
Can be used to provide an index to a columnar object without fully exporting the details
of the Index.
</t>
<t>
Abstract Data Type: unsigned32
</t>
<t>
Data Type Semantics: identifier
</t>
<t>
ElementId: TBD12
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- values -->
<section anchor="sectionIANANewElementsMIBFieldOption" title="New mibFieldOption 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 MIB OID encoded as ASN.1/BER <xref target="BER"/>
</t>
<t>
Abstract Data Type: octetArray
</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 Objects or IE for a mibField.
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 Columner Object represented by the mibFieldValue.
A bit set to value 0 indicates that this is not the case.
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 bits in the flowKeyIndicator for which no
corresponding Information Element exists MUST have the value
0.
</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 extracted 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 mibObjectValues that specify counters or statistics.
</t>
<t>
Values:
<list style="numbers">
<t>undefined</t>
<t>flow creation - The value for the MIB Object is captured from the MIB when the Flow is created</t>
<t>flow end - The value for the MIB Object is captured from the MIB when the Flow ends</t>
<t>flow export - The value for the MIB Object is captured from the MIB the Flow is being Exported</t>
<t>average - The value for the MIB Object is an average of multiple captures from the MIB over the 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 ( also known as snmpEngineID) that sepcifies 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>
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>
ElementId: TBD17
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- end mibFieldOption Fields -->
<section anchor="sectionIANANewElementsMIBTypeOption" title="New mibType 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 RFC 2578) of an object type definition.
</t>
<t>
Abstract Data Type: string
</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>
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.
This will start with abstract data structure of the MIB object which may be
a base type, the BITS construct, a textual convention, SEQUENCE OF or SEQUENCE.
This may be followed by subtyping or enumeration for the object. <xref target="RFC2578"/>
</t>
<t>
Abstract Data Type: string
</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 that defines a MIB OID Object.
</t>
<t>
Abstract Data Type: string
</t>
<t>
ElementId: TBD21
</t>
<t>
Status: current
</t>
<t>
Reference: [this document].
</t>
</list>
</t>
</section>
</section> <!-- end mibType fields -->
</section> <!-- New Information 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.</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;
&RFC2863;
&RFC4293;
&RFC7011;
&RFC7012;
&RFC3411;
<!-- Unreferenced: &RFC5226; -->
<!-- Unreferenced:
<reference anchor="PEN"
target="http://www.iana.org/assignments/enterprise-numbers">
<front>
<title>Private Enterprise Numbers registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
-->
<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>
<!-- Aiming for
[BER] 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.
Seems Old might be the right one.
-->
<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,</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date/>
</front>
</reference>
<!-- Unreferenced:
<reference anchor="IANA-SETS"
target="http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-set-ids">
<front>
<title>IPFIX Set IDs registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
-->
<reference anchor="IANA-DATATYPES"
target="http://www.iana.org/assignments/ipfix/ipfix.xml#ipfix-information-element-data-types">
<front>
<title>IPFIX Information Element Data Types registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
<seriesInfo name="" value=""/>
</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. -->
<!--
&RFC2981;
-->
&RFC2982;
&RFC3444;
&RFC4022;
<!--
&RFC5470;
-->
&RFC5476;
&RFC6313;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:16:50 |