Internet Engineering Task Force (IETF) | P. Aitken, Ed. |
Internet-Draft | Brocade Communications Systems, Inc. |
Intended status: Standards Track | B. Claise |
Expires: May 23, 2016 | S. B S |
Cisco Systems, Inc. | |
C. McDowall | |
Brocade Communications Systems, Inc. | |
J. Schoenwaelder | |
Jacobs University Bremen | |
November 20, 2015 |
Exporting MIB Variables using the IPFIX Protocol
draft-ietf-ipfix-mib-variable-export-10
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.
An IPFIX Options Template and method are specified, which are used to export the extra information required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 23, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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 [IANA-IPFIX], Information Elements coming from the SNMP world have already been specified, e.g., ingressInterface and egressInterface both refer to the ifIndex defined in [RFC2863].
In particular the Management Information Base was designed as a separate system of definitions which opens up the possibility of exporting Objects defined via the MIB over other protocols.
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 [RFC3444], both as SMIv2 MIB objects and IPFIX Information Elements, out of the same information model [RFC3444] would be avoided.
Therefore the primary goals of this document are:
The intended scope of this work is the addition of MIB variable(s) to IPFIX Information Elements in Data Records, in order to complement the Records with useful and already standardized information. Special consideration is given to the case of an existing Template Record which needs to be augmented with some MIB variables whose index is already present in the Template Record as an IPFIX Information Element. For example a 7-tuple Record containing the ingressInterface Information Element, which needs to be augmented by interface counters [RFC2863] which are indexed by the respective ingressInterface values which are already contained in the Data Records. See Section 3 for terminology definitions.
Many Data Records contain the ingressInterface and/or the egressInterface Information Elements. These Information Elements carry an ifIndex value, a MIB object defined in [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:
This document does not specify how to carry SNMP notifications in IPFIX, 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.
The Distributed Management Expression MIB [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 [RFC2982] could nicely complement Data Records.
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 [RFC2578], along with new Textual Conventions, can be exported within IPFIX and then decoded in the Collector. However, since a Textual Convention can contain almost any name, this document does not extend the existing informationElementDataType registry [IANA-IPFIX].
The overall architectural model is depicted in Figure 1. 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.
+------+ +-------+ +.........+ +.....+ | SNMP | | IPFIX | : NETCONF : : CLI : +------+ +-------+ +.........+ +.....+ | | | | +--------------------------------------------+ | Instrumentation (specified in MIB modules) | +--------------------------------------------+
Figure 1: Architectural Model
IPFIX-specific terminology (Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record, etc.) used in this document is defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized.
This document prefers the more generic term "Data Record" (as opposed to "Flow Record") in relation to the export of MIB objects.
Object Identifier (MIB OID)
MIB Object Identifier Information Element
SMIv2 Terminology
SMIv2 SYNTAX
SNMP Context Terminology
mibObjectValue Information Elements
IE
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 [RFC2119].
This document specifies a method for creating IPFIX Options Templates that are used to export the extra data required to describe MIB variables (see Section 5.1).
This allows IPFIX Templates to contain any combination of fields defined by traditional IPFIX Information Element(s) and/or MIB Object Identifier(s). The MIB Object Identifiers can reference either non-columnar or columnar MIB object(s). Enterprise-specific MIB Object Identifiers are also supported.
This document also defines two standard IPFIX Options Templates (see Section 5.3) that are used as part of the mechanism to export MIB object meta data:
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:
Additionally, this document defines two new IPFIX semantics which are required for the new Information Elements:
Two common types defined in the SMIv2 are conceptual rows and conceptual tables. It is desirable that exporting a complete or partial conceptual row is simple and efficient. This is accomplished by using IPFIX Structured Data [RFC6313] to reduce repetition of Object Identifier and indexing data.
To allow the use of individual columnar objects that make up a conceptual row, a method is also specified to detail that a MIB object is indexed by other fields in the same Data Flow. For an individually indexed mibObjectValue the INDEX fields are sent as any of the other fields in the same Record, and may be mibObjectValue Information Element(s) or other existing Information Element(s).
Also, in some cases Exporters may not want (or be able) to export the full information on how the MIB objects being exported are indexed. This may be because the MIB object is being used purely as type information or the Exporting Process may not have knowledge of the indexing required. Therefore providing index information for Columnar Objects is optional.
This document defines new mibObjectValue Information Elements (in Section 11.2.1). These are used to export MIB objects as part of standard IPFIX Templates. The mibObjectValue Information Elements contain the actual data values.
The Metering or Exporting Process may extract the data values for mibObjectValue Information Elements from a Process that resides on the same device or may capture or create the data required to match the definition of the MIB object. In particular exporting a value of a MIB object defined in a certain MIB module does not imply that the SNMP process on the device supports that MIB module.
The main issue that arises from exporting values of MIB objects in IPFIX is that MIB Object Identifiers do not fit into the standard IPFIX Template format [RFC7011], as this only provides a 16-bit Information Element identifier.
The values of a MIB object could be exported using a MIB specific Information Element without providing any Object Identifiers. However, without exporting the actual MIB OID the full type of the data would be unknown and every Field containing MIB object data would appear identical. Without knowing which OID the contents of a field map to, the data would be incomprehensible to a Collector.
For the values in the mibObjectValue Information Elements to be understandable, more meta information about the mibObjectValue Information Elements must be sent as part of the IPFIX export. The required minimum to understand each field is the OID as defined in Section 5.3.1.
One approach to this problem would be to extend the IPFIX standard to allow extended field specifiers so metadata about fields can be included in Data Templates. This would however require a new version of the IPFIX standard which may not be backwards compatible. However, future versions of IPFIX may export the required MIB metadata as part of newly defined IPFIX Set versions.
This document defines a MIB Field Options Template to export the extra meta information required for mibObjectValue Information Elements. This is a standard IPFIX Options Template Set which includes a minimum set of required fields (see Section 5.3.1) and may include extra fields to provide more meta information about one of the mibObjectValue Information Elements.
The MIB Field Options export is used to tell the Collecting process: for the following (template, field) the MIB Object type definition has this OID.
Four IPFIX Sets are used together to export a Flow which contains mibObjectValue Information Elements. These are:
Figure 2 shows the IPFIX Message structure for a MIB Field in a Template Set.
+-------------------------------------------------------+ | IPFIX Message Header | +-------------------------------------------------------+ | Template Set (A) | +-------------------------------------------------------+ | Options Template Set (B) (MIB Field Options Template) | +-------------------------------------------------------+ | Data Set (B) (MIB Field Options Data) | +-------------------------------------------------------+ | Data Set (A) | +-------------------------------------------------------+
Figure 2: IPFIX Message structure for a MIB Field in a Template Set
The MIB Field Options Template defines MIB Field Options Data Records. The MIB Field Options Data Records annotate the Data Template with mibObjectValue metadata. Together the Data Template and MIB Field Options Data Records define the Data Records that will be exported.
The Data Records (A) have a dependency on the two Templates and the MIB Field Options Data Records.
More Data Sets that use the same mibObjectValue Information Element can then be send in subsequent packets.
Figure 3 shows the relationships between the Sets discussed above.
+------------------------------+ |MIB Field Options Template (B)| +------------------------------+ |(templateId, elementIndex) | +------------------------------+ | mibOID | +------------------------------+ | | Defines V +------------------------+ +--------------------------+ | Data Template (A) | |MIB Field Options Data (B)| +------------------------+ +--------------------------+ |Field 0 - regular IE | | | +------------------------+ +--------------------------+ |Field 1-mibObjectValue | <----------- | (X,1) = OID | +------------------------+ Annotates +--------------------------+ |Field 2-mibObjectValue | <----------- | (X,2) = OID | +------------------------+ +--------------------------+ | | |------------------------------------/ | | Defines | V +------------------------+ | Data Records (A) | |------------------------| | Field 0 data | +------------------------+ | Field 1 data | +------------------------+ | Field 2 data | +------------------------+
Figure 3: Relationships between Sets
[RFC2578] specifies that the SYNTAX clause for a MIB object defines the abstract data structure of an Object and what it must contain:
"The data structure must be one of the following: a base type, the BITS construct, or a textual convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see section 7.1.12)." (From [RFC2578] section 7.1).
For each of the SYNTAX clause options this document specifies exactly which mibObjectValue Information Element to use.
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.
If the SYNTAX clause contains a Textual Convention or Subtyping the mibObjectSyntax Information Element SHOULD be used to export this detail to the Collecting Process.
The Options for the SYNTAX are then mapped as follows:
RFC2578 Section | SYNTAX | mibObjectValue IE |
---|---|---|
7.1.1 | INTEGER/Integer32 | mibObjectValueInteger |
7.1.2 | OCTET STRING | mibObjectValueOctetString |
7.1.3 | OBJECT IDENTIFIER | mibObjectValueOID |
7.1.4 | The BITS construct | mibObjectValueBits |
7.1.5 | IpAddress | mibObjectValueIPAddress |
7.1.6 | Counter32 | mibObjectValueCounter |
7.1.7 | Gauge32 | mibObjectValueGauge |
7.1.8 | TimeTicks | mibObjectValueTimeTicks |
7.1.9 | Opaque | mibObjectValueOctetString |
7.1.10 | Counter64 | mibObjectValueCounter |
7.1.11 | Unsigned32 | mibObjectValueUnsigned |
7.1.12 | SEQUENCE | mibObjectValueRow or |
mibObjectValueTable |
Values are encoded as per the standard IPFIX encoding of Abstract Data Types. The only new encoding reference in this document is that Object Identifiers (OID) will be encoded as per ASN.1/BER [BER] in an octetArray.
The mibObjectValue and mibObjectIdentifier Information Elements are standard IPFIX fields. Therefore the E bit of the mibObjectValue or mibObjectIdentifier Information Elements is set to "0".
The MIB object being exported may be defined in an enterprise-specific MIB module but the Information Elements defined in this standard are still exported with the E bit set to "0". The OID exported encodes that the MIB object was defined in a enterprise-specific MIB Module.
For each mibObjectValue Information Element that is defined in an IPFIX Template, a MIB Field Options Data Record will be exported that provides the required minimum information to define the MIB object that is being exported (see Section 5.3.1).
The MIB Field Options Data Records are defined in a template referred to in this document as a MIB Field Options Template with the format specified in Section 5.4.
The MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any Template that is using a mibObjectValue Information Element. Note that this places an implicit size constraint on the export.
This whole set of Templates and MIB Field Options Data Records MUST all be exported prior to the corresponding Data Records which depend upon them. i.e., the export order MUST be:
Note that the ID of an identical MIB Field Options Template which has already been exported MAY be reused without exporting the Template again.
IPFIX Set IDs are defined in section 3.3.2 of [RFC7011]. A value of 2 indicates a Template Set, a value of 3 indicates an Options Template Set, and values 256 and above indicate Data Sets.
Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Information Element with a MIB Field Options Template: Section 5.4.2).
These are the minimum fields required in a MIB Field Options Template (see
The mibObjectIdentifier is used to provide the OID for all mibObjectValue Information Elements exported except for when Structured Data is being used to export a conceptual row (see Section 5.8.2).
While the following are optional, they are nevertheless RECOMMENDED in certain circumstances as described in the referenced sections:
There are also fields that provide type information from a MIB object definition that MAY be exported to a Collecting Process.
Type information is statically defined in a MIB module; it is not expected to change. However, the additional information about the MIB object may help a Collecting Process that does not have access to the MIB module.
To export a MIB Type Options Template, the mibObjectIdentifier is RECOMMENDED as a Scope Field so that it matches the MIB Field Options Template. Any combination of the other MIB Type fields may be included.
The Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard IPFIX format as defined in [RFC7011], so a field using a mibObjectValue Information Element is specified using standard IPFIX Field Specifiers as in [RFC7011].
The only extra requirement on a Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified for EACH mibObjectValue Information Element (see Section 5.3.1).
If Multiple MIB Field Options Data Records that refer to a mibObjectValue are received the latest MUST be used. This matches the expected behavior of IPFIX Templates.
There is a one to one mapping between each mibObjectValue Information Element and a MIB Field Options Data Record.
A MIB Field Options Template and corresponding Data Record MUST be exported to provide the minimum required metadata.
Figure 4 shows an IPFIX Template Set using a mibObjectValue Information Element.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = Existing IPFIX Field | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = <mibObjectValue> | Field Length (MIB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPFIX Template Set using mibObjectValue Information Element
Where:
The MIB Field Options Template is a Standard Options Template which defines the Fields that will be exported to provide enough metadata about a mibObjectValue Information Element so that the Collector can tie the data values in the mibObjectValue Information Element back to the definition of the MIB object.
All MIB Field Options Templates contain the fields as specified in Section 5.3.1.
Figure 5 shows the required fields to export a mibObjectIdentifier for the MIB Field Options Template format.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MIB Field Options Template Format - Required Fields
Where:
The MIB Field Options Data Records conform to the Template Specification in the MIB Field Options Template. There may be multiple MIB Field Options Data Records exported.
The Collecting Process MUST store all received MIB Field Options Data information for the duration of each Transport Session, because the Collecting Process will need to refer to the extra meta information to fully decode each mibObjectValue Information Element.
Figure 6 shows the format of the exported MIB Field Options Data Record detailing the metadata that will be exported to match the Template in Figure 5.
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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of MIB Field Options Data Record
The Options Template Record format of a Template that uses a mibObjectValue Information Element is identical to the standard format as defined in [RFC7011]. The mibObjectValue Information Element is specified using standard Field Specifiers as in [RFC7011].
A mibObjectValue Information Element can be either a Scope Field or a non-Scope Field in an Options Template Record.
The only extra requirement on a Options Template Record using mibObjectValue Information Element is that it MUST export the required metadata specified in Section 5.3.1 for EACH mibObjectValue Information Element.
An IPFIX Options Template Record MUST export a MIB Field Options Template and Data Record to provide the minimum required metadata for each mibObjectValue Information Element.
Figure 7 shows an IPFIX Options Template Set using an existing IPFIX Field as a Scope Field and with a mibObjectValueInteger IE as a non-Scope Field, while Figure 8 shows an IPFIX Options Template Set using a mibObjectValueInteger IE as a Scope Field with an existing IPFIX Field as a non-Scope Field.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = Existing IPFIX Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPFIX Options Template Set using a Non Scope mibObjectValueInteger Field
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = Existing IPFIX Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPFIX Options Template Set using a Scope mibObjectValueInteger Field
A MIB Field Options Template MAY specify that extra Information Elements will be exported to record how the mibObjectValue was collected.
Alternatively, one of the existing IPFIX observationTime* elements [IANA-IPFIX] may be exported to specify exactly when the value was collected.
Figure 9 shows the MIB Field Options Template for a non-columnar Field with Semantic Data.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibCaptureTimeSemantics| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: MIB Field Options Template for a non-indexed Field with Semantic Data
Where:
The OID exported within the mibObjectIdentifier IPFIX Information Element provides a OID reference to a MIB object type definition that will fully describe the MIB object data being Exported.
However an Exported Process MAY decide to include some extra fields to more fully describe the MIB Object that is being exported with a mibObjectValue Information Element.
This can be helpful if the Collecting Process may not have access to the MIB module.
The Exporting Process can either include the extra object details fields as part of the MIB Field Options Template, or export a separate Options Template and Data that maps MIB OIDs in mibObjectIdentifier Fields to the object details.
If only a few fields are being exported then including extra type data in the MIB Field Options export will be more efficient.
The MIB Field Options Template for a non-indexed Field with extra MIB object details is shown in Figure 10.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 38 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectSyntax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectDescription | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibModuleName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MIB Field Options Template for a non-indexed Field with extra MIB object details
Where:
The MIB details can be exported as an standard IPFIX Option export [RFC7011] as shown in Figure 11. This may be more efficient as the bulk of this data is text based and SHOULD be exported only once to the Collecting Process if there are many MIB objects being exported. This prevents this large textual data being included for every use of a mibObjectValue Information Element.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectSyntax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibObjectDescription | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 |0| IE = mibModuleName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Alternative mibObjectIdentifier Option Export with object details
The MIB Field Options Template export makes use of the informationElementIndex [IANA-IPFIX] to specify which field in the template that the metadata relates to, which avoids any ordering constraints on the data template. The mibObjectValue Information Elements in a IPFIX export can be in any order in the export packet. However, fields used as an INDEX MUST be in the same order as specified in the INDEX clause of the conceptual row MIB object.
The informationElementIndex specifies which Field in the Template extra information is being provided for.
This is analogous to standard IPFIX Template Sets which also specify the order of the fields and provide their type and size.
If the template changes such that the order is different then the MIB Field Options data MUST be resent to reflect the new ordering. A new Template ID MUST be used to reflect that the ordering has changed. Older MIB Field Options Data may refer to the incorrect field.
A templateId [IANA-IPFIX] is only locally unique within a combination of a Observation Domain and Transport session. As such each MIB Field Options Data Record can only refer to templateIds within the same Observation Domain and session.
Each MIB OID is looked up in a specific context, usually the default context. If exporting a MIB OID value that isn't in the default context then the context MUST be identified by including the mibContextEngineID (see Section 11.2.2.5) and mibContextName (see Section 11.2.2.6) fields in the MIB Field Options Template and associated MIB Field Options Data Records, or be included in the same template as the mibFieldValue Field.
This context data MUST be included for each field that is not in the default context.
The context information MAY be exported as part of the Template that includes the mibObjectValue Information Element or the context information MAY be exported in the MIB Field Options Data Record that refers to the field. Context fields exported in the same Template MUST take precedence over those that refer to the template. Context fields MUST apply to all mibObjectValue Information Elements in the same template and there MUST NOT be duplicates of mibContextName or mibContextEngineID in a Template.
So a MIB Field Options Template MAY specify no Context information, just the Context Engine ID or both the context engine and context name. This allows the exporter to export the bulk of data in the default context and only tag those required.
Since the MIB Field Options Template applies for all the records of a Template using Context Fields in the MIB Field Options Data Template requires that each mibContextEngineID / mibContextName pair have its own Template.
Templates are managed as per section 8 of [RFC7011] with the additional constraint that the MIB Field Options Template and MIB Field Options Data Records MUST be exported in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element.
When exporting over an SCTP transport [RFC4960], the MIB Field Options Data Records MUST be exported reliably and in the same SCTP stream as their associated Templates per [RFC6526].
If a Template using a mibObjectValue Information Element is resent for any reason the Records it depends on MUST be sent as well.
If a Template is replaced with a new (Option) Template then a new MIB Field Options Data Record MUST be sent with the replacement referencing the new Template ID.
An Exporting Process SHOULD reuse MIB Field Options Template IDs when the Templates are identical. Each (Option) Template Record MUST still be accompanied by a copy of the MIB Field Options Template.
The requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any (Option) Template Record that uses a mibObjectValue Information Element may result in very large IPFIX Messages.
In environments with restricted Message sizes, and only when a reliable SCTP transport is being used, the MIB Field Options Template, MIB Field Options Data, Data Template, and Data Records, MAY be exported in separate Messages in the same SCTP stream, provided that their order is maintained.
Data Records containing mibObjectValue Information Elements MUST NOT be exported if their corresponding Data Template or MIB Field Options Template has been withdrawn, since the MIB Field Options Template MUST be exported in the same IPFIX Message as the Data Template which it annotates, except as allowed by the caveat of Section 5.7.1.
MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates.
There are three approaches for an IPFIX Exporting Process to export the values of columnar objects:
Firstly, a subordinate columnar object may be used purely as a data type. In this case there is no index information or relation to a conceptual row object provided by the Exporting Process.
Secondly, mibObjectValueRow or mibObjectValueTable can be used to export partial or complete conceptual rows using [RFC6313] structured data.
Thirdly, in a mixed option/data IPFIX/MIB template, the mibObjectValue Information Element can have the values of the INDEX clause of the conceptual row provided by other fields in the record. In this case each mibObjectValue Information Element must specify which other field(s) in the template is providing the index information.
This document defines two forms of indexing that can be used for conceptual row MIB objects.
Structured Data based indexing is used solely by the mibObjectValueRow Information Element. Each conceptual row of the MIB object corresponds to a single Data Record exported. The index fields defined in the INDEX clause of the MIB object MUST all be present in the same order as the Scope Fields. This allows a simple table export of a conceptual row MIB object without any extra fields required to indicate which fields make up the conceptual row INDEX.
Field based indexing is used by giving each mibObjectValue Information Element a mibIndexIndicator to flag the required index fields. This allows complex indexing or mixing of existing IPFIX Information Element with MIB Fields with minimum overhead. It also allows multiple Columnar MIB objects from different conceptual rows to be exported with complete indexing in one IPFIX Template.
The simplest approach to exporting a complete or partial conceptual row object is done with the mibObjectValueRow Information Element.
This is a Structured Data subTemplateList Information Element as detailed in [RFC6313]. The template specified MUST be an Options Template. It also MUST have the fields specified in the INDEX clause of the conceptual row object as the Scope Fields for the Option Export.
An overview of this architecture is given in Figure 12. This shows that the full MIB object type definition OID is exported for the mibObjectValueRow conceptual row field but that the individual columnar objects only require the subIdentifier to be exported. To make the diagram clearer the Templates for the MIB Field Options Templates are not shown.
+---------------------------+ +------------------------+ | Data Template | | MIB Field Options Data | | | | | | mibObjectValueRow |<---| OID | +---------------------------+ +------------------------+ | | +-----------------------+ +------------------------+ | | Options Template | | MIB Field Options Data | | | | | | | | Scope mibObjectValue* |<---| subIdentifiers | | | mibObjectValue* |<---| subIdentifiers | | +-----------------------+ +------------------------+ | | V V +---------------------------+ | Data Flows | | | | subTemplateList (1 entry) | +---------------------------+
Figure 12: Architecture for Exporting Conceptual Rows with mibObjectValueRow
The mibIndexIndicator is not required for each individual mibObjectValue Information Element as mibObjectValueRow provides a structure that includes the index details.
When Structured Data based indexing is used all Scope Fields MUST be the INDEX Objects in the same order as defined in the INDEX clause of the conceptual row being exported.
Each conceptual table MIB object has 2 related OIDs. There is an OID that refers to the Table with syntax of SEQUENCE OF and an OID that refers to each entry or conceptual row with the syntax of SEQUENCE. The OID for the SEQUENCE of a conceptual row MUST be exported.
For example in the IF-MIB ([RFC2863]) the OID for ifEntry should be exported rather than the OID for ifTable. The OID for the table (in this case ifTable) can be derived by removing one subidentifier from the ifEntry OID.
The Full OID for the conceptual row MIB object type definition being exported with the mibObjectValueRow Information Element MUST be exported. However the fields that are members of the conceptual row need not have the full OID of their MIB object type definition exported. Instead the mibSubIdentifier Information Element can be used to document which entry in the conceptual row the Field is.
In this case the export flow will contain a single complete or partial row from a table inside a single field of the record.
There may be MIB objects that are specified in the INDEX of the conceptual row but not columnar objects of the same conceptual row, for these the Exporter MUST provide the full OID in a mibObjectIdentifier field.
So for a conceptual row object with the OID "1.2.3.4.5.6" the OID of the type definitions for columnar objects "1.2.3.4.5.6.1" "1.2.3.4.5.6.2" can be exported with just a subIdentifier of "1" and "2" respectively.
The mibObjectValue Information Elements exported using the mibObjectValueRow export MUST all either be Objects defined in the INDEX clause, Columnar Objects of the same conceptual row object or Columnar Objects that AUGMENT the same conceptual row.
The [RFC6313] Structured Data subTemplateList format requires a Structured Data Type Semantic to be specified. Unless there is a more appropriate option in the IPFIX Structured Data Types Semantics registry ([IANA-IPFIX-SDTS]) the "undefined" Structured Data Type Semantic can be used.
Figure 13 shows an IPFIX Template for a Structured Data export of a conceptual row, while Figure 14 shows an IPFIX Options Template for a complete conceptual row with five columns and two INDEX fields. Figure 15 shows the MIB Field Options Template for a conceptual row field. Figure 16 shows the MIB Field Options Template for the columns inside the conceptual row. Figure 17 shows the OID data for the conceptual row would be exported.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 300 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPFIX Template for a Conceptual Row
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 301 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValue INDEX1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue INDEX2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValue COLUM5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: IPFIX Options Template for a mibObjectValueRow with 5 columns and 2 INDEX fields
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 302 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: MIB Field Options Template for a Conceptual Row Object
Where:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 303 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: MIB Field Options Template for Columnar Objects of a Conceptual Table
Where:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 302 | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 300 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 303 | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | templateId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | templateId = 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 301 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: mibOption Data Record for the conceptual row
Where:
SMIv2 defines conceptual rows as either having an INDEX clause or an AUGMENTS clause. Conceptual row definitions with an AUGMENTS clause extend an existing base conceptual row with an INDEX clause. It is not possible in SMIv2 to AUGMENT a conceptual row that itself has an AUGMENTS clause. The base table and the augmentation have an identical INDEX.
Since augmentations allow adding extra columns to existing tables it is beneficial to be able to support them easily in IPFIX exports of conceptual rows.
The mibObjectValueRow OID MAY refer either to the base table with the INDEX clause, or to a conceptual row with an AUGMENTS clause. The subIdentifiers in any MIB Field Options Data Record MUST always refer to the OID exported for the mibObjectValueRow IE.
If the mibObjectValueRow OID refers to a base table then any extra columns from conceptual rows with an AUGMENTS clause MUST have their full OID exported.
If the mibObjectValueRow OID refers to a conceptual row that augments another conceptual row using the AUGMENTS clause then any MIB fields from the original table's INDEX or Columnar Objects MUST NOT use the mibSubIdentifier and MUST instead export the full OID in a mibObjectIdentifier.
If the mibObjectValueRow refers to an AUGMENTS conceptual row the Scope Fields of the Template using in the subTemplateList MUST have the INDEX fields from the base table, in the same order as its scope. This is identical to the Scope Field requirements for conceptual rows with an INDEX clause.
This flexibility is provided so that the conceptual rows with the most columns can be exported using the more efficient mibSubIdentifier. For example exporting a complete set of augmentation columns would only require the full OIDs for the MIB objects in the INDEX.
It is possible to export MIB object columns from multiple AUGMENTS conceptual rows. If this is done then the base table SHOULD be used as the main OID for the mibObjectValueRow.
Multiple rows of a conceptual table can be exported in the mibObjectValueTable Information Element (Section 11.2.1.10). This allows a set of conceptual rows corresponding to a conceptual table to be exported as a single field. Therefore a complete set of rows can be exported as a single field with other information elements in a Template. In this fashion several complete conceptual tables could be exported in one packet.
Identically with mibObjectValueRow, as in section Section 5.8.2 above, the more specific OID of the SEQUENCE entity MUST be exported.
The format of mibObjectValueTable is identical to mibObjectValueRow except that the length of the subTemplateList may be 0 or more entries.
All the other, non length, requirements for mibObjectValueRow in Section 5.8.2 apply to mibObjectValueTable.
An overview of this architecture is given in Figure 18. This shows the similarity to Figure 12
+---------------------------+ +------------------------+ | Data Template | | MIB Field Options Data | | | | | | mibObjectValueTable |<---| OID | +---------------------------+ +------------------------+ | | +-----------------------+ +------------------------+ | | Options Template | | MIB Field Options Data | | | | | | | | Scope mibObjectValue* |<---| subIdentifiers | | | mibObjectValue* |<---| subIdentifiers | | +-----------------------+ +------------------------+ | | V V +-----------------------------+ | Data Flows | | | | subTemplateList (n entries) | | row 1 | | ... | | row n | +-----------------------------+
Figure 18: Architecture for Exporting Conceptual Tables with mibObjectValueTable
The other option for indexing a Columnar Object that is part of a conceptual table is explicit indexing. In this case there may be non index fields in the scope of the option export or there may be columnar MIB objects from multiple conceptual rows being exported. In this case each mibObjectValue Information Element requires the mibIndexIndicator with the bits set for the fields that are used to index that individual columnar object.
The index fields MUST be in the 'correct' order as defined in the conceptual row that each columnar object is a member of.
If a mibObjectValue Information Element that is being indexed using mibIndexIndicator is being used as an Options Template Scope Field, then all fields used to index that field MUST also be Scope Fields.
Figure 19 shows the MIB Field Options Template for an indexed MIB Columnar Object.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: MIB Field Options Template for an indexed MIB Columnar Object
Where:
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.
The table of data that is to be exported looks like:
TIMESTAMP | ESTABLISHED TCP CONN. |
---|---|
StartTime + 0 seconds | 10 |
StartTime + 60 seconds | 14 |
StartTime + 120 seconds | 19 |
StartTime + 180 seconds | 16 |
StartTime + 240 seconds | 23 |
StartTime + 300 seconds | 29 |
The Template Record for such a Data Record will detail two Information Elements:
Figure 20 shows the exported Template Set detailing the Template Record for exporting the number of established TCP connections.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 400 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = flowStartSeconds | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Example of tcpCurrEstab Template Set
Figure 21 shows the exported MIB Field Options Template Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 401 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Example of tcpCurrEstab MIB Field Options Template Set
Figure 22 shows the exported MIB Field Options Data Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 400 in Template Record.
The OID for the MIB object tcpCurrEstab from [RFC4022], Object ID "1.3.6.1.2.1.6.9", will be encoded in ASN.1/BER [BER] as '06072b060102010609' in the data record, which takes nine octets.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 401 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 400 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=9 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 06072b060102010609 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Example of tcpCurrEstab MIB Field Options Data Set
Figure 23 shows the start of the Data Set for exporting the number of established TCP connections (see Section 6.1).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 400 | Length = 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 0 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 60 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 120 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 180 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 240 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StartTime + 300 seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Example of tcpCurrEstab Data Set
For the sake of demonstrating a enterprise-specific MIB object from the CISCO-PROCESS-MIB ([CISCO-PROCESS-MIB]) is chosen. This example would be valid with any enterprise-specific MIB module.
The CPU Usage of a remote network device with 1 CPU could be monitored by configuring it to periodically export CPU usage information, i.e., the cpmCPUTotal1minRev from the proprietary CISCO-PROCESS-MIB, Object ID "1.3.6.1.4.1.9.9.109.1.1.1.1.7", to a centralized Collector.
Although the cpmCPUTotal1minRev MIB object is a columnar object in a conceptual row, while there is only 1 CPU no extra information is conveyed by providing the INDEX field. So in this case it is acceptable to not export the cpmCPUTotalIndex MIB object. If there were multiple CPUs it would be appropriate to include this the cpmCPUTotalIndex field and specify the relationship.
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.
The table of data that is to be exported looks like:
TIMESTAMP | CPU BUSY PERCENTAGE |
---|---|
StartTime + 0 seconds | 10% |
StartTime + 60 seconds | 14% |
StartTime + 120 seconds | 19% |
StartTime + 180 seconds | 16% |
StartTime + 240 seconds | 23% |
StartTime + 300 seconds | 29% |
The Template Record for such a Data Record will detail two Information Elements:
Figure 24 shows the exported Template Set detailing the Template Record for exporting CPU Load (see Section 6.2).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 402 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = flowStartSeconds | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Example of CPU Load Template Set
Figure 25 shows the exported Template Set detailing the MIB Field Options Template for exporting CPU Load (see Section 6.2). Note this is identical to the MIB Field Options Template given in Figure 21 so the same template could have been reused.
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 403 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Example of CPU Load MIB Field Options Template Set
Figure 26 shows the exported MIB Field Options Data Set detailing the metadata that will be exported about the mibObjectValueGauge Information Element in Template 402 in Template Record (see Section 6.2).
The OID for the cpmCPUTotal1minRev has been encoded using ASN.1/BER to '060d2b0601040109096d0101010107' at 15 octets long.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 403 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 402 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=15 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.4.1.9.9.109.1.1.1.1.7" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060d2b0601040109096d0101010107 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Example of CPULoad MIB Field Options Data Set
Note that although cpmCPUTotal1minRev is 32 bits long, reduced size encoding [RFC7011] has been used to encode it within a single octet. The encoding size was specified by setting the length for the mibObjectValueGauge Field to 1 octet in the main Data Template - Figure 24.
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.
The corresponding Data Set does not add any value for this example, and is therefore not displayed.
Many conceptual tables are already defined in standard and proprietary MIBs. These can be exported with a minimum of overhead by using the mibObjectValueRow. This allows the Exporting Process to unambiguously define the INDEX for the entire conceptual row as the Scope Fields of an Option Export. The use of a MIB Field Options Template with mibSubIdentifier being used means that each individual columnar object does not need to have its OID exported to the collector
The ospfNbrTable defined in the OSPF MIB [RFC4750] consists of ospfNbrEntry, which has the OID "1.3.6.1.2.1.14.10.1". Each mibObjectValueRow data record will therefore correspond to an ospfNbrEntry.
The following fields will be exported:
Object | ID | mibObjectValue | Len |
---|---|---|---|
ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 |
ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 |
-LessIndex | |||
ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 |
ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 |
The OIDs that will be used to export this table are shown in Table 5.
Entity | Full OID | Exported as |
---|---|---|
ospfNbrEntry | 1.3.6.1.2.1.14.10.1 | 1.3.6.1.2.1.14.10.1 |
ospfNbrIpAddr | 1.3.6.1.2.1.14.10.1.1 | 1 |
ospfNbrAddress- | 1.3.6.1.2.1.14.10.1.2 | 2 |
-LessIndex | ||
ospfNbrRtrId | 1.3.6.1.2.1.14.10.1.3 | 3 |
ospfNbrState | 1.3.6.1.2.1.14.10.1.6 | 6 |
Figure 27 shows the Templates Exported to Support the mibObjectValueRow. Figure 28 shows the example OID Data for the conceptual row exported in mibObjectValueRow Figure 29 shows the example data export for a few neighbors in the table. This shows a Data Record in formatted as per IPFIX Structured Data [RFC6313] and using the the 'undefined' (= 0xFF) semantic [IANA-IPFIX-SDTS]. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 500 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 501 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 502 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 503 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Example of ospfNbrEntry Template and Options Template Sets
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 502 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 500 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B060102010E0A01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 503 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 501 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 501 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 501 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 3 | templateId = 501 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 3 | mibSubIdentifier = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Example of ospfNbrEntry OID Data export
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 500 | Length = 52 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 501 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 3.3.3.3 |ospfNbrState=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Example of Data Export for ospfNbrEntry
The ifTable defined in the [RFC2863] is augmented by the ifXTable (defined in the same MIB module).
The OID of the ifEntry is 1.3.6.1.2.1.2.2.1 which is encoded using ASN.1/BER to '06082B06010201020201' at 10 octets long, while the OID of the augmenting ifXEntry is 1.3.6.1.2.1.31.1.1.1 which is encoded using ASN.1/BER to '060a2b060102011f01010101' at 12 octets long.
This example demonstrates how columnar objects from the base conceptual row and the augmenting row can be exported in a single mibObjectValueRow Information Element.
Table 6 shows the fields which will be exported.
ifIndex | ifType | ifMtu | ifName |
---|---|---|---|
1 | ethernetCsmacd:6 | 1500 | Ethernet 10 |
2 | ethernetCsmacd:6 | 1500 | Ethernet 20 |
3 | ethernetCsmacd:6 | 1500 | FastEthernet 30 |
The OIDs that will be used to export this table are shown in Table 7.
Entity | Full OID | Exported as |
---|---|---|
ifEntry | 1.3.6.1.2.1.2.2.1 | OID = 1.3.6.1.2.1.2.2.1 |
ifIndex | 1.3.6.1.2.1.2.2.1.1 | subID = 1 |
ifType | 1.3.6.1.2.1.2.2.1.3 | subID = 3 |
ifMtu | 1.3.6.1.2.1.2.2.1.4 | subID = 4 |
ifName | 1.3.6.1.2.1.31.1.1.1.1 | OID = 1.3.6.1.2.1.31.1.1.1.1 |
Figure 30 shows the Templates Exported to Support the mibObjectValueRow Information Element. Figure 31 shows the example OID Data for the conceptual row exported in mibObjectValueRow to match Table 7. Figure 32 shows the example data export as per Table 6.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 600 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 601 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|IE =mibObjectValueOctetString| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 602 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 603 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Example of Augmented ifEntry Template and Options Template Sets
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 602 | Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 600 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifEntry = 1.3.6.1.2.1.2.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B06010201020201 | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=12 | mibObjectIdentifier ifName ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifName = 1.3.6.1.2.1.31.1.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060a2b060102011f01010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 603 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 601 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Example of Augmented ifEntry OID Data export
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 600 | Length = 68 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 11 | ifName = Ethernet 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 11 | ifName = Ethernet 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length = 15 | ifName = FastEthernet 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Example of Data Export for Augmented ifEntry
It may be that the full set of columnar objects that are supported by a conceptual row are not required to be exported. Rather than use the Structured Data method the mibIndexIndicator method can be used to provide the relation between fields.
This example shows the MIB Objects that are part of the INDEX of the conceptual row being exported in the correct order and then being referred to by using mibIndexIndicator.
This example shows the export of ipIfStatsInForwDatagrams from the IP-MIB [RFC4293]. ipIfStatsInForwDatagrams is a columnar object that is part of the conceptual table ipIfStatsTable. This is comprised of ipIfStatsEntry conceptual rows.
The ipIfStatsTable conceptual table is indexed by the ipIfStatsIPVersion and ipIfStatsIfIndex.
The Options Template Record for the example Data Record contains the following Information Elements:
Note ipIfStatsIfIndex has been reduce length encoded to 2 octets in the following example. An exporting device with more interfaces would use the full length.
Figure 33 shows the exported Options Template Set.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 701 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0|Scope 1=mibObjectValueInteger| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field 1 Length = 1 |0|Scope 2=mibObjectValueInteger| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field 1 Length = 2 |0| IE = mibObjectValueCounter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Example of an Options Template for an Indexed MIB Object with two indices.
Figure 34 shows the exported MIB Field Options Template used to export the required mibObjectValue Information Element metadata. This example of the MIB Field Options Template includes the mibIndexIndicator to indicate that some of the other fields in the data records are indexes.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 702 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Example of an MIB Field Options Template for an Indexed MIB Object with two indices.
Figure 35 shows the exported MIB Field Options Data used to export the required mibObjectValue Information Element metadata. Note that the first two Data Records have all their mibIndexIndicator bits set to 0. The third mibIndexIndicator has the value '11000000' to show that the first two fields in the record are the INDEX's for this columnar object.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 702 | Length = 58 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 701 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Index 00000000 | VLEN = 12 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.4.31.3.1.1" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F030101 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | templateId = 701 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 |Index 00000000 | VLEN = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibObjectIdentifier = "1.3.6.1.2.1.4.31.3.1.2" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F030102 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 701 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index 11000000 | VLEN = 12 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.4.31.3.1.12" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 060A2B06010201041F03010c ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: Example of an MIB Field Options Data Set for an Indexed MIB Object with two indices.
Figure 36 shows the Data Records that export the values of the 3 mibObjectValue Information Elements.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 701 | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipVer = 1 | ifIndex = 10 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | InForwDatagrams = 10000 | ipVer = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex = 10 | InForwDatagrams = 20000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: Example of an MIB Data Set for an Indexed MIB Object with two indices.
If a PSAMP Packet Report [RFC5476] was generated on any dropped packets on an interface then it may be desirable to know if the send queue on the output interface was full. This could be done by exporting the size of the send queue (ifOutQLen) in the same Data Record as the PSAMP Packet Report.
The exported data looks like:
SRC ADDR | DST ADDR | PAK LEN | OUTPUT INTERFACE | OUTPUT Q. LEN (ifOutQLen) |
---|---|---|---|---|
192.0.2.1 | 192.0.2.3 | 150 | Eth 1/0 (15) | 45 |
192.0.2.4 | 192.0.2.9 | 350 | Eth 1/0 (15) | 45 |
192.0.2.3 | 192.0.2.9 | 650 | Eth 1/0 (15) | 23 |
192.0.2.4 | 192.0.2.6 | 350 | Eth 1/1 (16) | 0 |
The ifOutQLen MIB object defined in the IF-MIB [RFC2863] provides the length of the output packet queue. This columnar object is part of the ifEntry conceptual row and indexed by the interface index (ifIndex).
This relationship between the ifOutQLen field and the index field is exported using mibIndexIndicator in the MIB Field Options Template. The value of "00010000" flags the index fields concisely.
The Template Record for the example Data Record contains the following Information Elements:
Figure 37 shows the exported Template Set detailing the Template for exporting a PSAMP Report with Interface Output Queue Length (ifOutQLen). Figure 38 and Figure 39 show the MIB Field Options Template and Data Record.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 703 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = sourceIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = destinationIPv4Address | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = totalLengthIPv4 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = egressInterface | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueGauge | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: Example of Template for a PSAMP Report with ifOutQLen indexed by egressInterface
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 704 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibIndexIndicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| IE = mibObjectIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Example of MIB Field Options Template for a PSAMP Report with ifOutQLen indexed by egressInterface
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 704 | Length = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 703 | informationElementIndex = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Index 00010000 | VLEN = 11 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.2.2.1.21" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06092B0601020102020115 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+
Figure 39: Example of MIB Field Options Data Record for a PSAMP Report with ifOutQLen indexed by egressInterface
The corresponding IPFIX Data Record is shown in Figure 40. 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.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 703 | Length = 84 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 150 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 650 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 (Eth 1/0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 (Eth 1/1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Example of PSAMP Packet Report with ifOutQLen indexed by egressInterface
If the Context used to export the MIB objects is the default one no extra context fields are required. This example demonstrates how to handle the case when the Context needs to be specified. It is based on the previous example Section 6.3.
The OSPF details exported of the conceptual row in Section 6.3 would be suitable if there were only one OSPF process running at the Observation Point. If multiple OSPF processes are present then they can be differentiated by also exporting the mibContextEngineID and mibContextName.
The following fields will be exported:
Object | ID | mibObjectValue | Len |
---|---|---|---|
ospfNbrIpAddr | ospfNbrEntry 1 | mibObjectValueIPAddress | 4 |
ospfNbrAddress- | ospfNbrEntry 2 | mibObjectValueInteger | 4 |
-LessIndex | |||
ospfNbrRtrId | ospfNbrEntry 3 | mibObjectValueIPAddress | 4 |
ospfNbrState | ospfNbrEntry 6 | mibObjectValueInteger | 1 |
The example contextEngineID matches the example from [RFC3411] for Acme Networks: "'800002b804616263'H (enterprise 696, string 'abc')"
Figure 41 shows the Templates Exported to support a mibObjectValueRow that is defined within a context. Figure 42 shows the example OID Data for the conceptual row exported in mibObjectValueRow. These are unchanged from the previous example. Figure 43 shows the example data for 2 OSPF neighbors. Although these have identical INDEX/scope values the context information indicates they come from different OSPF processes. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to '06082B060102010E0A01' at 10 octets long.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 800 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibContextEngineID | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibContextName | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectValueRow | Field Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 801 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| IE = mibObjectValueInteger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 22 | Template ID = 802 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Count = 3 | Scope Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = templateId | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = informationElementIndex| Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE = mibObjectIdentifier | Field Length = 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 803 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| IE = templateId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = informationElementIndex| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| IE = mibSubIdentifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Example of ospfNbrEntry Template and Options Template Sets with Context
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 802 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 800 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN=10 | mibObjectIdentifier = "1.3.6.1.2.1.14.10.1" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B060102010E0A01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 803 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 801 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 1 | templateId = 801 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 1 | mibSubIdentifier = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 801 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibSubIdentifier = 3 | templateId = 801 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | informationElementIndex = 3 | mibSubIdentifier = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42: Example of ospfNbrEntry OID Data export with Context
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 800 | Length = 60 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextEngineID = 800002b804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextEngineID = 800002b804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 43: Example of Data Export for ospfNbrEntry with Context
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 Section 5.6.
The specifications in section 9 of [RFC7011] also apply to Collectors that implement this specification. In addition, the following specifications should be noted.
A Collecting Process that implements this specification MUST store the data records containing the OID Object Type Definitions with the same retention policy as templates.
A Collecting Process that implements this specification SHOULD have access to MIB modules in order to look up the received MIB Object Identifiers and find the full type definition and name of MIB OID fields used in received templates.
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.
If a Collecting Process receives a MIB Object Identifier that it cannot decode, it MAY log a warning.
A Collecting Process MUST support the 3 options for handling columnar objects detailed in Section 5.8.
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 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 [RFC2863] indexed using the ingressInterface Information Element. This would give the input statistics for each interface which can be compared to the flow information to ensure the sampling rate is expected. Or, if there is no sampling, to ensure that all the expected packets are being monitored.
For this extension to the IPFIX protocol, the same security considerations as for the IPFIX protocol apply [RFC7011].
If the exporter is generating or capturing the field values itself, e.g., using the MIB objects only as an encoding or type mechanism, there are no extra security considerations beyond standard IPFIX.
However, if the exporter is implemented as an SNMP manager accessing an SNMP agent, it MUST authenticate itself to the SNMP agent [RFC3414], [RFC5591], [RFC5592], [RFC6353], and the SNMP agent MUST enforce SNMP access control rules [RFC3415] as required by the SNMP architecture [RFC3411].
The access to particular MIB objects is controlled by the configuration of the IPFIX exporter. This is consistent with the way IPFIX controls access to other Information Elements in general.
The configuration of an IPFIX Exporter determines which MIB objects are included in IPFIX Data Records sent to certain collectors. Network operators should take care that the only MIB objects which are included in IPFIX Data Records are ones which the receiving flow collector is allowed to receive. Note that multiple users may have access to the data from the flow collector.
When exporting MIB objects that may be considered sensitive or vulnerable in some network environments (as mentioned in the Security Considerations section of the RFC containing the MIB module), the Exporter should consider using "IP Flow Anonymization Support" [RFC6235] if the information is anonymizable. Consumers of exported data should therefore be able to handle the kinds of modifications to data described in [RFC6235].
New IPFIX semantics must be allocated in IANA's IPFIX registry [IANA-IPFIX] per section 6 of [RFC7012], as defined in the sub-sections below.
An integral value reporting the value of a counter, identical to the Counter32 and Counter64 semantics in [RFC2578], as determined by the field length.
This is similar to IPFIX's totalCounter semantic, except that total counters have an initial value of 0, while SNMP counters do not.
An integral value identical to the Gauge32 semantic in [RFC2578], and the Gauge64 semantic in [RFC2856], as determined by the field length.
The new Information Elements in Table 10 must be allocated in IANA's IPFIX registry [IANA-IPFIX], as defined in the sub-sections below.
In each case the "Units" and "Range" are to be left blank, since these are not applicable.
ElementId | Name |
---|---|
TBD1 | mibObjectValueInteger |
TBD2 | mibObjectValueOctetString |
TBD3 | mibObjectValueOID |
TBD4 | mibObjectValueBits |
TBD5 | mibObjectValueIPAddress |
TBD6 | mibObjectValueCounter |
TBD7 | mibObjectValueGauge |
TBD8 | mibObjectValueTimeTicks |
TBD9 | mibObjectValueUnsigned |
TBD10 | mibObjectValueTable |
TBD11 | mibObjectValueRow |
TBD12 | mibObjectIdentifier |
TBD13 | mibSubIdentifier |
TBD14 | mibIndexIndicator |
TBD15 | mibCaptureTimeSemantics |
TBD16 | mibContextEngineID |
TBD17 | mibContextName |
TBD18 | mibObjectName |
TBD19 | mibObjectDescription |
TBD20 | mibObjectSyntax |
TBD21 | mibModuleName |
A new Information Element "mibObjectValueInteger" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueOctetString" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueOID" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueBits" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueIPAddress" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueCounter" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueGauge" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueTimeTicks" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueUnsigned" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueTable" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectValueRow" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectIdentifier" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibSubIdentifier" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibIndexIndicator" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibCaptureTimeSemantics" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibContextEngineID" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibContextName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectDescription" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibObjectSyntax" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
A new Information Element "mibModuleName" must be allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition:
The authors would like to thank Andrew Johnson for his collaboration on the first version of the draft, and to thank Andrew Feren and Brian Trammell for their detailed reviews.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.