Internet Engineering Task Force (IETF) P. Aitken, Ed.Internet-DraftRequest for Comments: 8038 BrocadeCommunications Systems, Inc. Intended status:Category: Standards Track B. ClaiseExpires: May 24, 2016ISSN: 2070-1721 Cisco Systems, Inc. S. B SCisco Systems,Mojo Networks, Inc. C. McDowall BrocadeCommunications Systems, Inc.J. Schoenwaelder Jacobs University BremenNovember 21, 2015May 2017 Exporting MIB VariablesusingUsing theIPFIXIP Flow Information Export (IPFIX) Protocoldraft-ietf-ipfix-mib-variable-export-10Abstract This document specifies a way to complementIPFIXIP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existingManagement Information BaseMIB objects that are already fully specified.AnTwo IPFIX OptionsTemplate andTemplates, as well as a methodare specified, whichfor creating IPFIX Options Templates that are used to export the extrainformationdata required to fully describe Simple Network Management Protocol (SNMP) MIB objects inIPFIX.IPFIX, are specified herein. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 24, 2016.http://www.rfc-editor.org/info/rfc8038. Copyright Notice Copyright (c)20152017 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3....................................................4 2. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . 4......................................................5 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 6.....................................................7 4.High LevelHigh-Level Solution Overview. . . . . . . . . . . . . . . . 7....................................8 5. MIB Object Value Information Elements and the MIB Field Options Template. . . . . . . . . . . . . . . . . . . . . . 8...............................................10 5.1. MIB Field Options Architecture. . . . . . . . . . . . . 9............................11 5.2. IPFIX and MIB Data Model. . . . . . . . . . . . . . . . 12..................................13 5.3. MIB Field Options - Specifications and Required Fields. 13....15 5.3.1. MIB Field Options Template. . . . . . . . . . . . . 14.........................16 5.3.2. MIB Type Options Template. . . . . . . . . . . . . . 14..........................16 5.4. MIB Field Options Template Formats. . . . . . . . . . . 15........................17 5.4.1. Data TemplatecontainingContaining amibObjectmibObjectValue Field. . . . . 15....17 5.4.2. MIB Field Options Template. . . . . . . . . . . . . 16.........................19 5.4.3. MIB Field Options Data Records. . . . . . . . . . . 18.....................20 5.4.4. Options TemplatecontainingContaining amibObjectmibObjectValue Field. . . . 19...............................21 5.4.5. MIB Field Options Template with Semantics Fields. . 20...23 5.4.6. MIB Field Options Template withextraExtra MIB Object Details. . . . . . . . . . . . . . . . . . . . . . . 21.....................................24 5.5. Use offield orderField Order in the MIB FieldOption template . . . 24Options Template ......27 5.6. Identifying the SNMP Context. . . . . . . . . . . . . . 24..............................27 5.7. Template Management. . . . . . . . . . . . . . . . . . . 25.......................................28 5.7.1. Large Messages. . . . . . . . . . . . . . . . . . . 25.....................................28 5.7.2. Template Withdrawal and Reuse. . . . . . . . . . . . 26......................29 5.8. Exporting Conceptual Rows and Tables. . . . . . . . . . 26......................29 5.8.1. Exporting Conceptual Rows -indexing . . . . . . . . 26Indexing ...............30 5.8.2. Exporting Conceptual Rows - mibObjectValueRow. . . . 27......30 5.8.3. Exporting Conceptual Rows -Augments . . . . . . . . 33AUGMENTS ...............36 5.8.4. Exporting Conceptual Tables - mibObjectValueTable. . 34..37 5.8.5. Exporting ColumnarObjects - usingObjects: Using mibIndexIndicator35..................................38 6. Example Use Cases. . . . . . . . . . . . . . . . . . . . . . 36..............................................39 6.1.Non ColumnarNon-columnar MIB Object: Established TCP Connections. . 37......39 6.2.Enterprise SpecificEnterprise-Specific MIB Object: Detailing CPU Load History. . . . . . . . . . . . . . . . . . . . . . . . . 40...................................................42 6.3. Exporting a Conceptual Row: The OSPF Neighbor Row. . . . 43.........45 6.4. Exporting Augmented Conceptual Row:TheMapping IF-MIBidID toname mapping . . . . . . . . . . . . . . . . . . . . . . . . . 47Name ................................................49 6.5. Exporting a Columnar Object:TheipIfStatsInForwDatagrams51.....55 6.6. Exporting a Columnar ObjectindexedIndexed byIEs:Information Elements: ifOutQLen. . 55.......................................58 6.7. ExportingWithwith Multiple Contexts: The OSPF Neighbor Row Revisited. . . . . . . . . . . . . . . . . . . . . . . . 59....................................62 7. Configuration Considerations. . . . . . . . . . . . . . . . 62...................................65 8. The Collecting Process's Side. . . . . . . . . . . . . . . . 62..................................66 9. Applicability. . . . . . . . . . . . . . . . . . . . . . . . 63..................................................66 10. Security Considerations. . . . . . . . . . . . . . . . . . . 63.......................................67 11. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 64...........................................68 11.1. New IPFIX Semantics. . . . . . . . . . . . . . . . . . 64......................................68 11.1.1. snmpCounter. . . . . . . . . . . . . . . . . . . . 64.......................................68 11.1.2. snmpGauge. . . . . . . . . . . . . . . . . . . . . 64.........................................68 11.2. New IPFIX Information Elements. . . . . . . . . . . . . 65...........................69 11.2.1. New MIB Object Value Information Elements. . . . . . . . . 65.........69 11.2.2. New MIB Field Options Information Elements. . . . . 71........75 11.2.3. New MIB Type Information Elements. . . . . . . . . 75.................79 12.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 13.References. . . . . . . . . . . . . . . . . . . . . . . . . 76 13.1.....................................................81 12.1. Normative References. . . . . . . . . . . . . . . . . . 76 13.2......................................81 12.2. Informative References. . . . . . . . . . . . . . . . . 78...................................82 Acknowledgments ...................................................84 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 79................................................84 1. Introduction There is growing interest in usingIPFIXIP Flow Information Export (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 toflowsFlows as they are understood today. For example, in the IPFIXinformation modelInformation Model [IANA-IPFIX], Information Elements coming from the SNMP world have already been specified, e.g., ingressInterface and egressInterface both refer to the ifIndex object as defined in [RFC2863]. Inparticularparticular, the Management Information Base was designed as a separate system ofdefinitions whichdefinitions; this opens up the possibility of exportingObjectsobjects defined via the MIB over other protocols. Rather than mapping existing MIB objects to IPFIX Information Elements on acase by casecase-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 ofdata modelsData Models [RFC3444], both as SMIv2 MIB objects and IPFIX Information Elements, out of the sameinformation modelInformation Model [RFC3444] would be avoided.ThereforeTherefore, the primary goals of this document are: o to specify a way to complement IPFIX Data Records withManagement Information Base (MIB)MIB objects; o to avoid the need to define new IPFIX Information Elements for existingManagement Information BaseMIB objects that are already fully specified; o to allow the correlation of SNMP and IPFIX sourced data by exporting them together; and o to allow SNMP push data from SNMP-only devices to be more easily integrated intoIPFIX basedIPFIX-based collection infrastructures. 2. Motivation 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 Data Records with useful andalready standardizedalready-standardized information. Special consideration is given to the case of an existing Template Recordwhichthat needs to be augmented with some MIB variables whose index is already present in the Template Record as an IPFIX InformationElement. For exampleElement -- for example, a 7-tuple Data Record containing the ingressInterface Information Element, which needs to be augmented by interface counters [RFC2863]whichthat are indexed by the respective ingressInterface valueswhich arealready 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: o It requires implementing a mediation function between twodata models,Data Models, i.e., MIB objects and IPFIX Information Elements. o Confirming the validity of simple mappings (e.g., ifIndex to ifName) requires either checking on a regular basis that the Exporter's network management system did notreload,reload or imposing ifIndex persistence across an Exporter's reload. o Synchronization problems occursincebecause counters carried in Data Records and counters carried in SNMP messages are retrieved from the Exporter at different points in time and thus cannot be correlated. In the best case, assuming very tight integration of an IPFIX Collector with an SNMP polling engine, SNMP data is retrieved shortly after Data Records have been received, which implies a delay of the sum of the active orinactiveidle timeouts (if not null) plus the time to export the Data Record to the Collector. If, however, the SNMP data is retrieved by a generic Network Management Station (NMS) polling interface statistics, then the time lag between IPFIX counters and SNMP counters can be significantly higher. See[RFC5470] section 5.1.1. "Flow Expiration"[RFC5102] for detailsofregarding active andinactiveidle timeouts. 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][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 newTextual Conventions,textual conventions, can be exported within IPFIX and then decoded in the Collector. However, since aTextual Conventiontextual convention can contain almost any name, this document does not extend the existinginformationElementDataType registry [IANA-IPFIX]."IPFIX Information Elements" subregistry [IANA-IPFIX] that contains informationElementDataType. 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 managementinterfacesinterfaces, such asNETCONFthe Network Configuration Protocol (NETCONF) or the device's Command Line Interface(CLI)(CLI), may provide access to the same instrumentation. +------+ +-------+ +.........+ +.....+ | SNMP | | IPFIX | : NETCONF : : CLI : +------+ +-------+ +.........+ +.....+ | | | | +--------------------------------------------+ | Instrumentation (specified in MIB modules) | +--------------------------------------------+ Figure 1: Architectural Model 3. Terminology IPFIX-specific terminology (Information Element, Template, Template Record, Options Template Record, Template Set, Collector, Exporter, Data Record, Transport Session, Exporting Process, Collecting Process, 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) An Object Identifier value is an ordered list of non-negative numbers. FortheSMIv2, each number in the list is referred to as a sub-identifier. There are at most 128 sub-identifiers in a value, and each sub-identifier has a maximum value of 2^32 - 1 (4294967295 decimal). See[RFC2578][RFC2578], Section 3.5. MIB Object Identifier Information Element An IPFIX Information Element ("mibObjectIdentifier")whichthat denotes that a MIB Object Identifier (MIB OID) is exported in the (Options) Data Record. See Section 11.2.2.1. SMIv2 Terminology The key words "MIBModule",module", "MIBObject",object", "INDEX", "AUGMENTS", "textual convention", "columnar object", "conceptual row", and "conceptual table" in this document are to be interpreted as described in SMIv2[RFC2578][RFC2578]. SMIv2 SYNTAX The SYNTAX key words "INTEGER", "Integer32", "OCTET STRING", "OBJECT IDENTIFIER","BITS construct","BITS", "IpAddress", "Counter32", "Gauge32", "TimeTicks", "Opaque", "Counter64", "Unsigned32", "SEQUENCE", and "SEQUENCE OF" in this document are to be interpreted as described in SMIv2 [RFC2578]. SNMP Context Terminology The key words "snmpEngineID", "contextEngineID", and "contextName" in this document are to be interpreted as described in[RFC3411][RFC3411]. mibObjectValue Information ElementsRefers"mibObjectValue Information Elements" refers to any and all of the mibObjectValue Information Elements generically. Any restriction or requirement in this document that refers tomibObjectValue"mibObjectValue" applies to the following Information Elements as defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBits, mibObjectValueIPAddress,mibObjectValueBITS,mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow. Abstract Data Type Abstract Data Types for IPFIX are defined in Section 3.1 of [RFC7012]. This specification uses the Abstract Data Types "unsigned8", "unsigned32", "unsigned64", "signed32", "octetArray", "string", "ipv4Address", and "subTemplateList". IE Used asashorthand for "Information Element" [RFC7011] in the figures. 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]. 4.High LevelHigh-Level Solution Overview 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 eithernon- columnarnon-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 objectmeta data:metadata: o MIB Field Options Template (Section 5.3.1) o MIB Type Options Template (Section 5.3.2) 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 MIBModule:module: o MIB Object Value Information Elements (Section 11.2.1) o MIB Field Options Information Elements (Section 11.2.2) o MIB Type InformationInformationElements (Section 11.2.3) Additionally, this document defines two new IPFIX semanticswhichthat are required for the new Information Elements: o snmpCounter (Section 11.1.1) o snmpGauge (Section 11.1.2) Two common types defined intheSMIv2 are conceptual rows and conceptual tables. It is desirable that exporting a complete or partial conceptual rowisbe 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 todetailexplain that a MIB object is indexed by other fields in the same Data Flow. For an individually indexedmibObjectValuemibObjectValue, theINDEXindex fields are sent in the same way as any of the other fields in the sameRecord,Data 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.ThereforeTherefore, providing index information forColumnar Objectscolumnar objects is optional. 5. MIB Object Value Information Elements and the MIB Field Options Template 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 Process 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. Inparticularparticular, 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 aMIB specificMIB-specific InformationElementElement, without providing any Object Identifiers. However, without exporting the actual MIBOIDOID, the full type of the data would beunknownunknown, and everyFieldfield 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, moremeta informationmeta-information about the mibObjectValue Information Elements must be sent as part of the IPFIX export. The required minimum information to understand each field that isthe OID as definedbeing exported is provided in Section 5.3.1. One approach to this problem would be to extend the IPFIX standard to allow extendedfield specifiersField Specifiers so that metadata about fields can be included in Data Templates. Thiswould howeverwould, however, require a new version of the IPFIX standardwhichthat may not bebackwardsbackward 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 extrameta informationmeta-information required for mibObjectValue Information Elements. This is a standard IPFIX Options Template Setwhichthat includes a minimum set of required fields (see Section 5.3.1) and may include extra fields to provide moremeta informationmeta-information about one of the mibObjectValue Information Elements. The MIB Field Options exportis used to telltells the Collectingprocess: forProcess thefollowing (template, field)OID for the MIBObjectobject type definitionhas this OID.for the following (Template, field). 5.1. MIB Field Options Architecture Four IPFIX Sets are used together to export a Flowwhichthat contains mibObjectValue Information Elements. These are: 1. A Template Setwhichthat includes the mibObjectValue Information Element. The Template Set informs the Collector that a MIB object value of length N will be exported. This Set may also be an Options Template Set. 2. A MIB Field Options TemplateSetSet. The MIB Field Options Template describes which metadata will be sent for each mibObjectValue Information Element being exported. 3. A MIB Field Options DataSetSet. The MIB Field Options Data Set includes the metadata for each MIB object (i.e., the mibObjectIdentifier or mibSubIdentifier). The metadata about the mibObjectValue Information Elements only needs to be resent as per normal Template refreshes or resends. 4. A Data Set. The Data Set contains only the actual data extracted from the MIB or described by the MIB module. Figure 2 shows the IPFIX Message structure for a MIBFieldfield 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 MessagestructureStructure 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.TogetherTogether, 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 besendsent 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 5.2. IPFIX and MIB Data Model[RFC2578][RFC2578], Section 7.1 specifies that the SYNTAX clause for a MIB object defines the abstract data structure of anObjectobject and what it must contain: "The data structure must be one of the following: a base type,the BITS construct,BITS, 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 clauseoptionsoptions, this document specifies exactly which mibObjectValue Information Element to use. If a MIB object to be exported is aTextual Convention,textual convention, the definition of theTextual Conventiontextual convention must be consulted and the SYNTAX clause used to determine the correct base type. This may recurse if theTextual Conventiontextual convention is defined in terms of anotherTextual Conventiontextual convention, but this should end at a base type. If the SYNTAX clause contains aTextual Conventiontextual convention orSubtypingsub-typing (e.g., integerSubType, octetStringSubType) [RFC2578], the mibObjectSyntax Information Element SHOULD be used to export this detail to the Collecting Process. TheOptionsoptions for the SYNTAX clause are then mapped as follows:+-----------------+---------------------+---------------------------++-------------+-------------------+---------------------------------+ |RFC2578Section in | SYNTAX | mibObjectValueIEInformation | | RFC 2578 | | Element |+-----------------+---------------------+---------------------------++-------------+-------------------+---------------------------------+ | 7.1.1 | INTEGER/Integer32 | mibObjectValueInteger | | 7.1.2 | OCTET STRING | mibObjectValueOctetString | | 7.1.3 | OBJECT IDENTIFIER | mibObjectValueOID | | 7.1.4 |TheBITSconstruct| 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 | mibObjectValueRowor| | 7.1.12 | SEQUENCE OF | mibObjectValueTable |+-----------------+---------------------+---------------------------++-------------+-------------------+---------------------------------+ Table 1: SMIv2 SYNTAX to mibObjectValuetypesTypes 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)(OIDs) will be encoded as per ASN.1/BER[BER][X.690] in an octetArray. The mibObjectValue and mibObjectIdentifier Information Elements are standard IPFIX fields.ThereforeTherefore, the E bit of the mibObjectValue or mibObjectIdentifier Information Elements is set to"0".0. The MIB object being exported may be defined in an enterprise- specific MIBmodulemodule, but the Information Elements defined in this standard are still exported with the E bit set to"0".0. The OID being exportedencodesindicates that the MIB object was defined ina enterprise- specifican enterprise-specific MIBModule.module. 5.3. MIB Field Options - Specifications and Required Fields 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 atemplateTemplate 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 Recordswhichthat depend upon them.i.e.,That is, the export order MUST be: 1. Data Template for mibObjectValue Information Elements (Set ID 2) 2. MIB Field Options Template (Set ID 3) 3. MIB Field Options Data Records (Set ID >= 256) 4. MIB Object Value Data Records (Set ID >= 256) Note that the ID of an identical MIB Field Options Templatewhichthat has already been exported MAY be reused without exporting the Template again. IPFIX Set IDs are defined insectionSection 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. 5.3.1. MIB Field Options Template Three fields are REQUIRED to unambiguously export a standalone mibObjectValue Information Element with a MIB Field Options Template: o (scope) templateId [IANA-IPFIX] o (scope) informationElementIndex [IANA-IPFIX] o mibObjectIdentifier (Section 11.2.2.1) or mibSubIdentifier (Section 11.2.2.2) These are the minimum fields required in a MIB Field Options Template (see Section 5.4.2). The mibObjectIdentifier is used to provide the OID for all mibObjectValue Information Elementsexportedexported, exceptforwhen IPFIX Structured Data [RFC6313] is being used to export a conceptual row (see Section 5.8.2). While the following are optional, they are nevertheless RECOMMENDED in certaincircumstancescircumstances, as described in the referenced sections: o mibCaptureTimeSemantics (discussed in Section 5.4.5;IEInformation Element defined in Section 11.2.2.4) o mibIndexIndicator (discussed in Section 5.8.5;IEInformation Element defined in Section 11.2.2.3) o mibContextEngineID (discussed in Section 5.6;IEInformation Element defined in Section 11.2.2.5) o mibContextName (discussed in Section 5.6;IEInformation Element defined in Section 11.2.2.6) 5.3.2. MIB Type Options Template 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. o (scope) mibObjectIdentifier (see Section 11.2.2.1) o mibObjectName (see Section 11.2.3.1) o mibObjectDescription (see Section 11.2.3.2) o mibObjectSyntax (see Section 11.2.3.3) o mibModuleName (see Section 11.2.3.4) 5.4. MIB Field Options Template Formats 5.4.1. Data TemplatecontainingContaining amibObjectmibObjectValue Field 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 Specifiersas inper [RFC7011]. The only extra requirement on a Template Record using one or more mibObjectValue InformationElementElements is that it MUST export the required metadata specified in Section 5.3.1 for EACH mibObjectValue InformationElement (see Section 5.3.1).Element. IfMultiplemultiple MIB Field Options Data Records that refer to a mibObjectValue arereceivedreceived, the latest MUST be used. This matches the expected behavior of IPFIX Templates. There is aone to oneone-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 SetusingUsing mibObjectValue Information Element Where: <mibObjectValue> One of the mibObjectValue IPFIX Information Elements that denotes thataMIB object data (i.e., the value of a MIB object) will be exported in the (Options)TemplateData Record. This could be any one of the mibObjectValue Information Elements defined in Section 11.2.1: mibObjectValueInteger, mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBits, mibObjectValueIPAddress,mibObjectValueBITS,mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTimeTicks, mibObjectValueUnsigned, mibObjectValueTable, and mibObjectValueRow. When a mibObjectValue Information Element is used, the MIB Object Identifier ("mibObjectIdentifier") MUST be exported via a MIB Field Optionsor by other means.Template and MIB Field Options Data Record. See Section 5.3.1. Field Length (MIB) The length of the encoded MIB object data in the corresponding Data Records, in octets.The definition is as [RFC7011].See [RFC7011] for a detailed definition. Note that the Field Length can be expressed usingreduced sizereduced-size encoding per [RFC7011]. Note that the Field Length may be encoded using variable-length encoding per [RFC7011]. 5.4.2. MIB Field Options Template The MIB Field Options Template is aStandardstandard Options Templatewhichthat defines theFieldsfields 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 fieldsasspecified 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: templateId The first Scope Field is an IPFIX Information Elementwhichthat denotes that a Template Identifier will be exported as part of the MIB Field Options Data Record. This TemplateIdentifierIdentifier, paired with an index into thattemplate, theTemplate (the "informationElementIndex"field,field), uniquely references one mibObjectValue Information Element being exported. informationElementIndex The second Scope Field is an IPFIX Information Elementwhichthat denotes azero basedzero-based index into the fields defined by a Template. When paired with a"templateId" the Record"templateId", this uniquely references one mibObjectValue Information Element being exported. mibObjectIdentifier An IPFIX Information Elementwhichthat denotes theaMIB Object Identifier for the mibObjectValue Information Element exported in the (Options) Template Record. When a MIB Object Value Information Element is used, the MIB Object Identifier MUST be specified in the MIB Field Options Template Record or specified by other means. The Object Identifier is encoded in the IPFIXdata recordData Record in ASN.1/BER[BER][X.690] format. Variable-length encoding SHOULD be used with the mibObjectIdentifier so that multipledifferent lengthMIB OIDs of different lengths can be exported efficiently. This will also allow reuse of the MIB Field Options Template. Variable-length encoding is indicated by the Field Length value of6553565535, persectionsSections 3.2 and 7 of [RFC7011]. The RECOMMENDED use ofvariable lengthvariable-length encoding for mibObjectIdentifier fields is indicated in subsequent figures by placing 65535 in the relevant length fields. 5.4.3. MIB Field Options Data Records 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 extrameta informationmeta-information to fully decode each mibObjectValue Information Element. Figure 6 shows the format of the exported MIB Field Options DataRecordRecord, 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifiercontinued(continued) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifiercontinued(continued) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of MIB Field Options Data Record VLEN contains the variable length of the mibObjectIdentifier per Section 7 of [RFC7011]. 5.4.4. Options TemplatecontainingContaining amibObjectmibObjectValue Field 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 Specifiersas inper [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 onaan Options Template Record using one or more mibObjectValue InformationElementElements 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 IPFIXFieldfield as a Scope Field and with a mibObjectValueIntegerIEInformation Element as anon- Scopenon-Scope Field, while Figure 8 shows an IPFIX Options Template Set using a mibObjectValueIntegerIEInformation Element as a Scope Field with an existing IPFIXFieldfield 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 SetusingUsing aNon ScopeNon-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 SetusingUsing a Scope mibObjectValueInteger Field 5.4.5. MIB Field Options Template with Semantics Fields 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-columnarFieldfield 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 anon-indexedNon-columnar Field with Semantic Data Where: mibObjectIdentifier Note the use ofvariable lengthvariable-length encoding for this field. mibCaptureTimeSemantics The MIB Capture Time Semantics IPFIX Information Element, as defined in Section 11.2.2.4. It is RECOMMENDED to include this field when exporting a mibObjectValue Information Element that specifies counters or statistics,in particularparticularly for situations withlong livedlong-lived Flows. 5.4.6. MIB Field Options Template withextraExtra MIB Object Details The OID exported within the mibObjectIdentifier IPFIX Information Element providesaan OID reference to a MIB object type definition that will fully describe the MIB object data beingExported. Howeverexported. However, anExportedExporting Process MAY decide to include some extra fields to more fully describe the MIBObjectobject 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 fields with extra object detailsfieldsas part of the MIB Field OptionsTemplate,Template or export a separate Options Template and a Data Record that maps MIB OIDs in mibObjectIdentifierFieldsfields to the object details. If only a few fields are beingexportedexported, then including extra type data in the MIB Field Options export will be more efficient. The MIB Field Options Template for anon-indexed Fieldnon-columnar 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 anon-indexedNon-columnar Field withextraExtra MIBobject detailsObject Details Where: mibObjectSyntax The MIB object syntax string as defined in Section 11.2.3.3. Note that a separate mibObjectSyntax Information Element is required (rather than extend the existinginformationElementDataType registry [IANA-IPFIX])"IPFIX Information Elements" subregistry [IANA-IPFIX] that contains informationElementDataType) because the SYNTAX clause could contain almost any name. mibObjectName The textual name of a mibObjectIdentifierObject.object. mibObjectDescription The textual description for a mibObjectIdentifier. mibModuleName The textual name of the MIB module that defines a MIBObject.object. Note the use ofvariable lengthvariable-length encoding for the mibObjectIdentifier, mibObjectSyntax, mibObjectName, mibObjectDescription, and mibModuleName, since these are all string fields. The MIB details can be exportedas an standardin Data Records specified using a regular IPFIXOption export [RFC7011]Options Template Record [RFC7011], as shown in Figure 11. This may be moreefficientefficient, 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 from 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 mibObjectIdentifierOption ExportOptions Template Set withobject detailsObject Details 5.5. Use offield orderField Order in the MIB FieldOption templateOptions Template The MIB Field Options Template export makes use of the informationElementIndex [IANA-IPFIX] to specify which field in thetemplate thatTemplate the metadata relatesto, whichto; this avoids any ordering constraints on thedata template.Data Template. The mibObjectValue Information Elements inaan IPFIX export can be in any order in the export packet. However, fields used as an INDEX MUST be in the same order as the order specified in the INDEX clause of the conceptual row MIB object. The informationElementIndex specifies whichFieldfield in the Template extra information is being provided for. This is analogous to standard IPFIX TemplateSetsSets, which also specify the order of the fields and provide their type and size. If thetemplateTemplate changes such that the order isdifferentdifferent, then the MIB Field OptionsdataData 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 ofaan Observation Domain and Transportsession.Session. Assuchsuch, each MIB Field Options Data Record can only refer to templateIds within the same Observation Domain and session. 5.6. Identifying the SNMP Context 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 defaultcontextcontext, 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 sametemplateTemplate as themibFieldValue Field.mibObjectValue 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 InformationElementElement, 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 thetemplate.Template. Context fields MUST apply to all mibObjectValue Information Elements in the sametemplateTemplate, and there MUST NOT be duplicates of mibContextName or mibContextEngineID in a Template.SoSo, a MIB Field Options Template MAY specify noContextcontext information, just theContext Enginecontext engine ID or both the context engine and context name. This allows theexporterExporter to export the bulk of data in the default context and only tag those items that are required. Since the MIB Field Options Template applies for all therecordsData Records of aTemplateTemplate, usingContext Fieldscontext fields in the MIB Field Options Data Template requires that each mibContextEngineID / mibContextName pair have its own Template. 5.7. Template Management Templates are managed as persectionSection 8 of[RFC7011][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)(Options) Template Record that uses a mibObjectValue Information Element. When exporting overan SCTPa Stream Control Transmission Protocol (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 anyreasonreason, the Data Records it depends on MUST be sent as well. If a Template is replaced with a new(Option) Template(Options) 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)(Options) Template Record MUST still be accompanied by a copy of the MIB Field Options Template. 5.7.1. Large Messages The requirement to export the MIB Field Options Template and MIB Field Options Data Records in the same IPFIX Message as any(Option)(Options) 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 DataRecords,Records MAY be exported in separate Messages in the same SCTP stream, provided that their order is maintained. 5.7.2. Template Withdrawal and Reuse 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 Templatewhichthat it annotates, except as allowed by the caveatofmentioned in Section 5.7.1. MIB Field Options Template IDs MUST NOT be reused while they are required by any existing Data Templates. 5.8. Exporting Conceptual Rows and Tables There are three approaches for an IPFIX Exporting Process to export the values of columnar objects: 1. Ignoring the indexing ofColumnar Objectscolumnar objects 2. Exporting conceptualrows/tablerows / table objects usingstructured dataIPFIX Structured Data [RFC6313] 3. Exporting individual indexedColumnar Objectscolumnar objects Firstly, a subordinate columnar object may be used purely as a data type. In thiscasecase, 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 conceptualrowsrows, using[RFC6313] structured data.IPFIX Structured Data [RFC6313]. Thirdly, in a mixed option/data IPFIX/MIBtemplate,Template, the mibObjectValue Information Element can have the values of the INDEX clause of the conceptual row provided by other fields in therecord.Data Record. In thiscasecase, each mibObjectValue Information Element must specify which other field(s) in thetemplateTemplate is providing the index information. 5.8.1. Exporting Conceptual Rows -indexingIndexing This document defines two forms of indexing that can be used for conceptual row MIBobjects.objects: Indexing based on IPFIX Structured Databased indexing[RFC6313] 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 basedField-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 InformationElementElements with MIBFieldsfields, with minimum overhead. It also allows multipleColumnarcolumnar MIB objects from different conceptual rows to be exported with complete indexing in one IPFIX Template. 5.8.2. Exporting Conceptual Rows - mibObjectValueRow The simplest approach to exporting a complete or partial conceptual row object is done with the mibObjectValueRow Information Element. This isaan IPFIX Structured Data subTemplateList Information Element as detailed in [RFC6313]. ThetemplateTemplate 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 Fieldsforin theOption Export.MIB Field Options Template and Data Set. 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 thesubIdentifiersub-identifier to be exported. To make the diagramclearerclearer, 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* |<---|subIdentifiersmibSubIdentifier | | | mibObjectValue* |<---|subIdentifiersmibSubIdentifier | | +-----------------------+ +------------------------+ | | 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 InformationElementElement, as mibObjectValueRow provides a structure that includes the index details. When indexing based on IPFIX Structured Databased indexing[RFC6313] isusedused, all Scope Fields MUST be the INDEXObjectsobjects in the same order as defined in the INDEX clause of the conceptual row being exported. Each conceptual table MIB object has2two related OIDs. There is an OID that refers to theTabletable with the 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. Forexampleexample, in the IF-MIB([RFC2863])[RFC2863], the OID for ifEntry should be exported rather than the OID for ifTable. The OID for the table (in thiscasecase, ifTable) can be derived by removing onesubidentifiersub-identifier from the ifEntry OID. TheFullfull OID for the conceptual row MIB object type definition being exported with the mibObjectValueRow Information Element MUST be exported.HoweverHowever, the fields that are members of the conceptual row need not have the full OID of their MIB object type definition exported.InsteadInstead, the mibSubIdentifier Information Element can be used to document which entry in the conceptual row theFieldfield is. In thiscasecase, theexport flowexported Flow will contain a single complete or partial row from a table inside a single field of therecord.Data Record. There may be MIB objects that are specified in the INDEX of the conceptual row but not columnar objects of the same conceptualrow,row; forthesethese, the Exporter MUST provide the full OID in a mibObjectIdentifier field.SoSo, 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 asubIdentifiermibSubIdentifier of "1" and"2""2", respectively. The mibObjectValue Information Elements exported using the mibObjectValueRow export MUST all either beObjectsobjects defined in the INDEX clause,Columnar Objectscolumnar objects of the same conceptual rowobjectobject, orColumnar Objectscolumnar objects thatAUGMENTaugment the same conceptual row. The[RFC6313]IPFIX Structured Data [RFC6313] subTemplateList format requiresathe Structured Data TypeSemanticSemantics to be specified. Unless there is a more appropriate option in theIPFIX"IPFIX Structured Data TypesSemantics registry ([IANA-IPFIX-SDTS])Semantics" subregistry [IANA-IPFIX], the "undefined" Structured Data TypeSemanticSemantics can be used. Figure 13 shows an IPFIX Template foraan IPFIX Structured Data [RFC6313] export of a conceptual row, while Figure 14 shows an IPFIX Options Template for a complete conceptual row with five columns and twoINDEXindex 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 OIDdataData for the conceptual rowwouldthat will 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 = mibObjectValueCOLUM3COLUMN3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValueCOLUM4COLUMN4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length |0| IE = mibObjectValueCOLUM5COLUMN5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: IPFIX Options Template for a mibObjectValueRow with5 columnsFive Columns and2 INDEX fieldsTwo 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: templateId The templateId for the MIBOptionoption that will be exported. mibObjectIdentifier The MIB OID for theConceptual Rowconceptual row that is being exported. Note the use ofvariable lengthvariable-length encoding for this 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 = 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: templateId The templateId used will be for the Template referred to in the subTemplateList of the mibObjectValueRow that will be exported. mibSubIdentifier Thesub identifiersub-identifier that specifies the columnar object's ID within the 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 = 302 | Length = N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 300 | informationElementIndex | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLEN | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifiercontinued(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 theconceptual rowConceptual Row Where: mibObjectIdentifier Will contain the OID for the conceptual row as a whole. mibSubIdentifier The mibSubIdentifier fields will contain the extraSub Identifier thatsub-identifier that, when added to the OID for the conceptualrow giverow, gives the full OID for theObject.object. 5.8.3. Exporting Conceptual Rows -AugmentsAUGMENTS SMIv2 defines conceptual rows aseitherhaving either 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 toAUGMENTaugment 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 existingtablestables, it is beneficial to be able to support them easily in IPFIX exports of conceptual rows. The mibObjectValueRow OID MAY refereitherto either the base table with the INDEXclause,clause ortoa conceptual row with an AUGMENTS clause. ThesubIdentifiersmibSubIdentifier in any MIB Field Options Data Record MUST always refer to the OID exported for the mibObjectValueRowIE.Information Element. If the mibObjectValueRow OID refers to a basetabletable, 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 AUGMENTSclauseclause, then any MIB fields from the original table's INDEX orColumnar Objectscolumnar objects MUST NOT use the mibSubIdentifier and MUST instead export the full OID in a mibObjectIdentifier. If the mibObjectValueRow refers to anAUGMENTSaugmenting conceptualrowrow, the Scope Fields of the Templateusingused in the subTemplateList MUST have theINDEXindex 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. Forexampleexample, 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 multipleAUGMENTSaugmenting conceptual rows. If this isdonedone, then the base table SHOULD be used as the main OID for the mibObjectValueRow. 5.8.4. Exporting Conceptual Tables - mibObjectValueTable 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.ThereforeTherefore, a complete set of rows can be exported as a single field with otherinformation elementsInformation Elements in a Template. In thisfashionfashion, several complete conceptual tables could be exported in one packet.Identically with mibObjectValueRow, as in section Section 5.8.2 above,As also specified for mibObjectValueRow (Section 5.8.2), the more specific (i.e., full) OID of the SEQUENCE entity MUST be exported. The format of mibObjectValueTable is identical tomibObjectValueRowmibObjectValueRow, except that the length of the subTemplateList may be0zero or more entries. All the other,non length,i.e., non-length, requirements for mibObjectValueRow in Section 5.8.2 apply to mibObjectValueTable. An overview of this architecture is given in Figure 18. Thisshows the similarityarchitecture is similar to the architecture shown in Figure1212. +---------------------------+ +------------------------+ | Data Template | | MIB Field Options Data | | | | | | mibObjectValueTable |<---| OID | +---------------------------+ +------------------------+ | | +-----------------------+ +------------------------+ | | Options Template | | MIB Field Options Data | | | | | | | | Scope mibObjectValue* |<---|subIdentifiersmibSubIdentifier | | | mibObjectValue* |<---|subIdentifiersmibSubIdentifier | | +-----------------------+ +------------------------+ | | V V +-----------------------------+ | Data Flows | | | | subTemplateList (n entries) | | row 1 | | ... | | row n | +-----------------------------+ Figure 18: Architecture for Exporting Conceptual Tables with mibObjectValueTable 5.8.5. Exporting ColumnarObjects - usingObjects: Using mibIndexIndicator The other option for indexing aColumnar Objectcolumnar object that is part of a conceptual table is explicit indexing. In thiscase there may be non index fields incase, the Options Template Set scopeof the option export or theremaybecontain either non-index fields or columnar MIB objects from multiple conceptual rows being exported. In thiscasecase, 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'"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 MIBColumnar Object.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 anindexedIndexed MIB Columnar Object Where: mibIndexIndicator The MIB Index Indicator IPFIX Information Elementwhichthat marks which fields in therecordData Record will act as INDEX values for the exported MIB object. The index data for a mibObjectValue will be other fields contained in the same Data Record. The mibIndexIndicator marks theFieldsfields whose value(s) should be added to the OID for the MIB object type definition exported in mibObjectIdentifier to get the OID for the instance of the MIB object. Elements used to index MIB objects MUST be exported in the same order as they are specified in theINDEXindex field of the conceptual table they belong to. mibObjectIdentifier Note the use ofvariable lengthvariable-length encoding for this field. 6. Example Use Cases 6.1.Non ColumnarNon-columnar MIB Object: Established TCP Connections 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 | +-------------------------+-----------------------+ Table 2: Established TCP Connections The Template Record for such a Data Record willdetailprovide details for the following two Information Elements: 1. flowStartSeconds from [IANA-IPFIX], Information Element 150: The absolute timestamp of the first packet of this Flow. 2. tcpCurrEstab from [RFC4022], Object ID "1.3.6.1.2.1.6.9": The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT. 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][X.690] as'06072b060102010609'"06072B060102010609" in thedata record,Data Record, which takesnine9 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 400 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=9VLEN = 9 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibObjectIdentifier = "1.3.6.1.2.1.6.9" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...06072b06010201060906072B060102010609 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 6.2.Enterprise SpecificEnterprise-Specific MIB Object: Detailing CPU Load History For the sake ofdemonstrating ademonstration, an enterprise-specific MIB object from the CISCO-PROCESS-MIB([CISCO-PROCESS-MIB])[CISCO-PROCESS-MIB] is chosen. This example would be valid with any enterprise-specific MIB module. The CPUUsageusage of a remote network device with1one CPU could be monitored by configuring it to periodically export CPU usage information, i.e., the cpmCPUTotal1minRev from the proprietaryCISCO- PROCESS-MIB,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,whileif there is only1one CPU no extra information is conveyed by providing theINDEXindex field.SoSo, in thiscasecase, it is acceptable to not export the cpmCPUTotalIndex MIB object. If there were multipleCPUsCPUs, it would be appropriate to includethisthe 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 CPU1 minute1-minute busy average at1 minute1-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% | +-------------------------+---------------------+ Table 3: CPU Usage Data The Template Record for such a Data Record willdetailprovide details for the following two Information Elements: 1. flowStartSeconds from [IANA-IPFIX], Information Element 150: The absolute timestamp of the first packet of this Flow. 2.aA mibObjectValueGauge for cpmCPUTotal1minRev, the overall CPU busy percentage in the lastone-minute1-minute period. 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 thisNote: This is identical to the MIB Field Options Template given in Figure2121, so the sametemplateTemplate could have been reused. 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 = 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'"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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 402 | informationElementIndex = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=15VLEN = 15 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.4.1.9.9.109.1.1.1.1.7" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |060d2b0601040109096d0101010107060D2B0601040109096D0101010107 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: Example ofCPULoadCPU Load MIB Field Options Data Set Note that although cpmCPUTotal1minRev is 32 bits long,reduced sizereduced-size encoding [RFC7011] has been used to encode it within a single octet. The encoding size was specified by setting the length for the mibObjectValueGaugeFieldfield to 1 octet in the main DataTemplate -Template; see 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" since0, because the"mibObjectValueGauge"mibObjectValueGauge and"mibObjectIdentifier"mibObjectIdentifier InformationElement isElements are 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 thisexample,example and is therefore not displayed. 6.3. Exporting a Conceptual Row: The OSPF Neighbor Row 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 anOption Export.Options Template Set. 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 thecollectorCollector. TheospfNbrTableospfNbrTable, defined in the OSPF MIB[RFC4750][RFC4750], consists of ospfNbrEntry, which has the OID "1.3.6.1.2.1.14.10.1". Each mibObjectValueRowdata recordData 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 | +------------------+----------------+-------------------------+-----+ Table 4: OSPF Neighbor Entry Objects 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 | +------------------+-----------------------+---------------------+ Table 5: OSPF OIDs Figure 27 shows the TemplatesExportedexported toSupportsupport the mibObjectValueRow. Figure 28 shows the example OID Data for the conceptual row exported inmibObjectValueRowmibObjectValueRow. Figure 29 shows the example data export for a few neighbors in thetable. Thistable; Figure 29 also shows a Data Recordinformatted as per IPFIX Structured Data [RFC6313] and using thethe 'undefined'"undefined" (= 0xFF) semantic[IANA-IPFIX-SDTS].from the "IPFIX Structured Data Types Semantics" subregistry [IANA-IPFIX]. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to'06082B060102010E0A01'"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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 500 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=10VLEN = 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 DataexportExport 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 6.4. Exporting Augmented Conceptual Row:TheMapping IF-MIBidID toname mappingName TheifTableifTable, defined in the[RFC2863]IF-MIB [RFC2863], is augmented by the ifXTable (defined in the same MIB module). The OID of the ifEntry is1.3.6.1.2.1.2.2.11.3.6.1.2.1.2.2.1, which is encoded using ASN.1/BER to'06082B06010201020201'"06082B06010201020201" at 10 octets long, while the OID of the augmenting ifXEntry is1.3.6.1.2.1.31.1.1.11.3.6.1.2.1.31.1.1.1, which is encoded using ASN.1/BER to'060a2b060102011f01010101'"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 fieldswhichthat 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 | +---------+------------------+-------+-------------------+ Table 6: IF-MIB Data 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 | +---------+------------------------+--------------------------------+ Table 7: IF-MIB OIDs Figure 30 shows the TemplatesExportedexported toSupportsupport 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 600 | informationElementIndex = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=10VLEN = 10 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifEntry = 1.3.6.1.2.1.2.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 06082B06010201020201 | Padding = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | templateId = 601 | informationElementIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=12VLEN = 12 | mibObjectIdentifier ifName ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifName = 1.3.6.1.2.1.31.1.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |060a2b060102011f01010101060A2B060102011F01010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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 DataexportExport 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |lengthLength = 11 | ifName = Ethernet 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |lengthLength = 11 | ifName = Ethernet 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 601 | ifIndex = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifType = 6 | ifMtu = 1500 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |lengthLength = 15 | ifName = FastEthernet 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 32: Example of Data Export for Augmented ifEntry 6.5. Exporting a Columnar Object:TheipIfStatsInForwDatagrams 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 IPFIX Structured Datamethod[RFC6313] method, the mibIndexIndicator method can be used to provide therelationrelationship between fields. This example shows the MIBObjectsobjects 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 ipIfStatsTable conceptualtable ipIfStatsTable.table. This is comprised of ipIfStatsEntry conceptual rows. The ipIfStatsTable conceptual table is indexed bytheipIfStatsIPVersion and ipIfStatsIfIndex. The Options Template Record for the example Data Record contains the following Information Elements: 1. ipIfStatsIPVersion (1.3.6.1.2.1.4.31.3.1.1) (Scope Field) (encoded using ASN.1/BER to'060A2B06010201041F030101'"060A2B06010201041F030101" at 12 octets long) 2. ipIfStatsIfIndex (1.3.6.1.2.1.4.31.3.1.2) (Scope Field) (encoded using ASN.1/BER to'060A2B06010201041F030102'"060A2B06010201041F030102" at 12 octets long) 3. ipIfStatsInForwDatagrams (1.3.6.1.2.1.4.31.3.1.12) (non-Scope Field) (encoded using ASN.1/BER to'060A2B06010201041F03010c'"060A2B06010201041F03010C" at 12 octets long) Note that ipIfStatsIfIndex has beenreduce lengthreduced-size 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 withtwo indices.Two Index Objects 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 thedata recordsData Records areindexes.index objects. 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 ofana MIB Field Options Template for an Indexed MIB Object withtwo indices.Two Index Objects 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'"00000011" to show that the first two fields in therecordData Record are theINDEX'sINDEXes 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index1100000000000011 | VLEN = 12 | mibObjectIdentifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "1.3.6.1.2.1.4.31.3.1.12" ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |060A2B06010201041F03010c060A2B06010201041F03010C ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: Example ofana MIB Field Options Data Set for an Indexed MIB Object withtwo indices.Two Index Objects Figure 36 shows the Data Records that export the values of the3three 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 ofana MIB Data Set for an Indexed MIB Object withtwo indices.Two Index Objects 6.6. Exporting a Columnar ObjectindexedIndexed byIEs:Information Elements: ifOutQLen If aPSAMPPacket Sampling (PSAMP) Packet Report [RFC5476] was generated on any dropped packets on aninterfaceinterface, 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 |PAKPKT LEN | OUTPUT | OUTPUTQ.QUEUE LEN | | | |LEN| INTERFACE | (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 |+-----------+-----------+--------+--------------+-------------------++-----------+-----------+---------+--------------+------------------+ Table 8: Packet Report with Interface Output Queue Length (ifOutQLen) Data The ifOutQLen MIBobjectobject, defined in the IF-MIB[RFC2863][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""00001000" flags the index fields concisely. The Template Record for the example Data Record contains the following Information Elements: 1. sourceIPv4Address 2. destinationIPv4Address 3. totalLengthIPv4 4. egressInterface 5. ifOutQLenindexed by: egressInterface(indexed by egressInterface) Figure 37 shows the exported Template Set detailing the Template for exporting a PSAMP Report withInterface Output Queue Length (ifOutQLen). FigureifOutQLen. Figures 38 andFigure39 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 ifOutQLenindexedIndexed 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 ifOutQLenindexedIndexed 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 703 | informationElementIndex = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Index0001000000001000 | 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 ifOutQLenindexedIndexed 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 ifOutQLenindexedIndexed by egressInterface 6.7. ExportingWithwith Multiple Contexts: The OSPF Neighbor Row Revisited If theContextcontext used to export the MIB objects is the defaultoneone, no extra context fields are required. This example demonstrates how to handle the case when theContextcontext needs to be specified. It is based on the previous exampleSection 6.3.(Section 6.3). The OSPF detailsexportedof the conceptual rowinthat was exported per Section 6.3 would be suitable if there were only one OSPF process running at the Observation Point. If multiple OSPF processes arepresentpresent, 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 | +------------------+----------------+-------------------------+-----+ Table 9: OSPF Neighbor Entry Objects The example contextEngineID matches the example from [RFC3411] for Acme Networks:"'800002b804616263'H"'800002B804616263'H (enterprise 696, string'abc')""abc")". Figure 41 shows the TemplatesExportedexported 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 previousexample.example (Section 6.3). Figure 43 shows the example data for2two OSPF neighbors. Although these have identical INDEX/scopevaluesvalues, the context information indicates that they come from different OSPF processes. Note that the OID for ospfNbrEntry has been encoded using ASN.1/BER to'06082B060102010E0A01'"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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |templateIdTemplate ID = 800 | informationElementIndex = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VLEN=10VLEN = 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 DataexportExport 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 =800002b804616263800002B804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr = 192.0.2.1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 1.1.1.1 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextEngineID =800002b804616263800002B804616263 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... mibContextEngineID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mibContextName = con2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Semantic=0xFF | Template ID = 801 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrIpAddr =192.0.2.1192.0.2.2 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrAddressLessIndex = 0 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ospfNbrRtrId = 2.2.2.2 |ospfNbrState=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 43: Example of Data Export for ospfNbrEntry with Context 7. Configuration Considerations When configuring a MIB OID for export, consideration should be given to whether the SNMPContext Stringcontext should also be configurable. If a non-defaultContext Stringcontext isusedused, then it should be associated with the fields as per Section 5.6. 8. The Collecting Process's Side The specifications insectionSection 9 of [RFC7011] also apply to Collectors that implement this specification. In addition, the following specifications should benoted.noted: o A Collecting Process that implements this specification MUST store thedata recordsData Records containing the OIDObject Type Definitionsobject type definitions with the same retention policy astemplates.Templates. o 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 receivedtemplates.Templates. o It should be notedthat since reduced sizethat, because reduced-size encoding MAY be used by the Exporting Process, the Collecting Process cannot assume that a received size for a field is the maximum size it should expect for that field. o If a Collecting Process receives a MIB Object Identifier that it cannot decode, it MAY log a warning. o A Collecting Process MUST support the3three options for handling columnar objects detailed in Section 5.8. 9. Applicability 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 usualflowFlow information. Some monitoring applications periodically exportana mapping of interface ID to interface namemappingusing IPFIX Options Templates. This could be expanded to include the ifInUcastPkts MIB object"ifInUcastPkts" ofas defined in the IF-MIB[RFC2863][RFC2863], indexed using the ingressInterface Information Element. This wouldgiveprovide the input statistics for eachinterface whichinterface; these statistics can be compared to theflowFlow information to ensure that the sampling rate isexpected. Or, if there is noas expected, or, in the absence of sampling, to ensure that alltheexpected packets are being monitored. 10. Security Considerations For this extension to the IPFIX protocol, the same security considerations as those for the IPFIX protocol apply [RFC7011]. If theexporterExporter 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 theexporterExporter is implemented as an SNMP manager accessing an SNMP agent, it MUST authenticate itself to the SNMP agent[RFC3414], [RFC5591], [RFC5592],[RFC3414] [RFC5591] [RFC5592] [RFC6353], and the SNMP agent MUST enforce SNMP access control rules [RFC3415] as required by the SNMP architecture [RFC3411].The accessAccess to particular MIB objects is controlled by the configuration of the IPFIXexporter.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 certaincollectors.Collectors. Network operators should take care that the only MIB objectswhichthat are included in IPFIX Data Records areones whichobjects that the receivingflow collectorCollector is allowed to receive. Note that multiple users may have access to the data from theflow collector.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"anonymization techniques per [RFC6235] if the information is anonymizable. Consumers of exported data should therefore be able to handle the kinds ofmodifications todata modifications that are described in [RFC6235]. 11. IANA Considerations 11.1. New IPFIX Semantics New IPFIX semanticsmust behave been allocated in IANA's IPFIX registry [IANA-IPFIX] persectionSection 6 of [RFC7012], as defined in thesub- sectionssubsections below. 11.1.1. snmpCounter An integral value reporting the value of a counter, identical to the Counter32 and Counter64 semantics in [RFC2578], as determined by thefield length.Field Length. This is similar to IPFIX's totalCounter semantic, except that total counters have an initial value of0, while0 but SNMP counters do not. IANA has assigned value 7 to snmpCounter. 11.1.2. snmpGauge An integral value identical to the Gauge32 semantic in[RFC2578],[RFC2578] and the Gauge64 semantic in [RFC2856], as determined by thefield length.Field Length. IANA has assigned value 8 to snmpGauge. 11.2. New IPFIX Information Elements The new Information Elements in Table 10must behave been allocated in IANA's IPFIX registry [IANA-IPFIX], as defined in thesub-sectionssubsections below. In eachcasecase, the "Units" and "Range"are to behave been left blank, since these are not applicable. +-----------+---------------------------+ | ElementId | Name | +-----------+---------------------------+ |TBD1434 | mibObjectValueInteger | |TBD2435 | mibObjectValueOctetString | |TBD3436 | mibObjectValueOID | |TBD4437 | mibObjectValueBits | |TBD5438 | mibObjectValueIPAddress | |TBD6439 | mibObjectValueCounter | |TBD7440 | mibObjectValueGauge | |TBD8441 | mibObjectValueTimeTicks | |TBD9442 | mibObjectValueUnsigned | |TBD10443 | mibObjectValueTable | |TBD11444 | mibObjectValueRow | |TBD12445 | mibObjectIdentifier | |TBD13446 | mibSubIdentifier | |TBD14447 | mibIndexIndicator | |TBD15448 | mibCaptureTimeSemantics | |TBD16449 | mibContextEngineID | |TBD17450 | mibContextName | |TBD18451 | mibObjectName | |TBD19452 | mibObjectDescription | |TBD20453 | mibObjectSyntax | |TBD21454 | mibModuleName | +-----------+---------------------------+ Table 10: New Information Elements 11.2.1. New MIB Object Value Information Elements 11.2.1.1. mibObjectValueInteger A new Information Element "mibObjectValueInteger"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that the integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of Integer32 and INTEGER with IPFIXReduced Size Encodingreduced-size encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type ofsigned64.signed32. Abstract Data Type:signed64signed32 Data Type Semantics:identifierquantity ElementId:TBD1434 Status: current Reference:[this document].RFC 8038 11.2.1.2. mibObjectValueOctetString A new Information Element "mibObjectValueOctetString"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that an Octet String or Opaque value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of OCTET STRING and Opaque. The value is encoded as per the standard IPFIX Abstract Data Type of octetArray. Abstract Data Type: octetArray Data Type Semantics: default ElementId:TBD2435 Status: current Reference:[this document].RFC 8038 11.2.1.3. mibObjectValueOID A new Information Element "mibObjectValueOID"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that an Object Identifier or OID value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of OBJECT IDENTIFIER.Note -Note: In thiscasecase, the "mibObjectIdentifier"will definedefines which MIB object is beingexported whileexported, and thevalue contained in this Information Element"mibObjectValueOID" field willbe ancontain the OIDas a value.value of that MIB object. The mibObjectValueOID Information Element is encoded as ASN.1/BER[BER][X.690] in an octetArray. Abstract Data Type: octetArray Data Type Semantics: default ElementId:TBD3436 Status: current Reference:[this document].RFC 8038 11.2.1.4. mibObjectValueBits A new Information Element "mibObjectValueBits"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that a set of Enumerated flags or bits from a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of BITS. The flags or bits are encoded as per the standard IPFIX Abstract Data Type of octetArray, with sufficient length to accommodate the required number of bits. If the number of bits is not an integer multiple ofoctetsoctets, then the most significant bits at the end of the octetArray MUST be set tozero.0. Abstract Data Type: octetArray Data Type Semantics: flags ElementId:TBD4437 Status: current Reference:[this document].RFC 8038 11.2.1.5. mibObjectValueIPAddress A new Information Element "mibObjectValueIPAddress"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that the IPv4Addressaddress value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax ofIPaddress.IpAddress. The value is encoded as per the standard IPFIX Abstract Data Type of ipv4Address. Abstract Data Type: ipv4Address Data Type Semantics: default ElementId:TBD5438 Status: current Reference:[this document].RFC 8038 11.2.1.6. mibObjectValueCounter A new Information Element "mibObjectValueCounter"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that the counter value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of Counter32 or Counter64 with IPFIXReduced Size Encodingreduced-size encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned64. Abstract Data Type: unsigned64 Data Type Semantics: snmpCounter ElementId:TBD6439 Status: current Reference:[this document].RFC 8038 11.2.1.7. mibObjectValueGauge A new Information Element "mibObjectValueGauge"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that the Gauge value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of Gauge32. The value is encoded as per the standard IPFIX Abstract Data Type ofunsigned64.unsigned32. This valuewill representrepresents a non-negativeinteger, whichinteger that may increase ordecrease,decrease but that shall never exceed a maximumvalue, norvalue or fall below a minimum value. Abstract Data Type: unsigned32 Data Type Semantics: snmpGauge ElementId:TBD7440 Status: current Reference:[this document].RFC 8038 11.2.1.8. mibObjectValueTimeTicks A new Information Element "mibObjectValueTimeTicks"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that the TimeTicks value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax of TimeTicks. The value is encoded as per the standard IPFIX Abstract Data Type of unsigned32. Abstract Data Type: unsigned32 Data Type Semantics:defaultquantity ElementId:TBD8441 Status: current Reference:[this document].RFC 8038 11.2.1.9. mibObjectValueUnsigned A new Information Element "mibObjectValueUnsigned"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that an unsigned integer value of a MIB object will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with the BaseSyntaxsyntax ofunsigned64unsigned32 with IPFIXReduced Size Encodingreduced-size encoding used as required. The value is encoded as per the standard IPFIX Abstract Data Type ofunsigned64.unsigned32. Abstract Data Type:unsigned64unsigned32 Data Type Semantics:identifierquantity ElementId:TBD9442 Status: current Reference:[this document].RFC 8038 11.2.1.10. mibObjectValueTable A new Information Element "mibObjectValueTable"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that a complete or partial conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with aSYNTAXsyntax ofSEQUENCE.SEQUENCE OF. This is encoded as a subTemplateList of mibObjectValue Information Elements. ThetemplateTemplate specified in the subTemplateList MUST be an Options Template and MUST include all theObjectsobjects listed in the INDEX clause as Scope Fields. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId:TBD10443 Status: current Reference:[this document].RFC 8038 11.2.1.11. mibObjectValueRow A new Information Element "mibObjectValueRow"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that a single row of a conceptual table will be exported. The MIB Object Identifier ("mibObjectIdentifier") for this field MUST be exported in a MIB Field Option or via another means. This Information Element is used for MIB objects with aSYNTAXsyntax of SEQUENCE. This is encoded as a subTemplateList of mibObjectValue Information Elements. The subTemplateList exported MUST contain exactly one row (i.e., one instance of thesubtemplate).subTemplate). ThetemplateTemplate specified in the subTemplateList MUST be an Options Template and MUST include all theObjectsobjects listed in the INDEX clause as Scope Fields. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId:TBD11444 Status: current Reference:[this document].RFC 8038 11.2.2. New MIB Field Options Information Elements 11.2.2.1. mibObjectIdentifier A new Information Element "mibObjectIdentifier"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: An IPFIX Information Elementwhichthat denotes that a MIB Object Identifier (MIB OID) is exported in the (Options) Template Record. The mibObjectIdentifier Information Element contains the OID assigned to the MIBObject Type Definitionobject type definition encoded asASN.1/ BER [BER]ASN.1/BER [X.690]. Abstract Data Type: octetArray Data Type Semantics: default ElementId:TBD12445 Status: current Reference:[this document].RFC 8038 11.2.2.2. mibSubIdentifier A new Information Element "mibSubIdentifier"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: A non-negative sub-identifier of an Object Identifier (OID). Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId:TBD13446 Status: current Reference:[this document].RFC 8038 11.2.2.3. mibIndexIndicator A new Information Element "mibIndexIndicator"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description:ThisA set of bit fields that is used for marking the Information Elements of a Data Record that serve as INDEX MIB objects for an indexedColumnarcolumnar MIB object. Each bit represents an Information Element in the DataRecordRecord, with the n-th least significant bit representing the n-th Information Element. A bit set tovalue1 indicates that the corresponding Information Element is an index of theColumnar Objectcolumnar object represented by themibFieldValue.mibObjectValue. A bit set tovalue0 indicates that this is not the case. If the Data Record contains more than 64 Information Elements, the corresponding Template SHOULD be designed such that allINDEX Fieldsindex fields are among the first 64 Information Elements, because the mibIndexIndicator only contains 64 bits. If the Data Record contains less than 64 Information Elements, then the extra bits in the mibIndexIndicator for which no corresponding Information Element exists MUST have the value0,0 and must be disregarded by the Collector. This Information Element may be exported with IPFIXReduced Size Encoding.reduced-size encoding. Abstract Data Type: unsigned64 Data Type Semantics: flags ElementId:TBD14447 Status: current Reference:[this document].RFC 8038 11.2.2.4. mibCaptureTimeSemantics A new Information Element "mibCaptureTimeSemantics"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: Indicates when in the lifetime of theflowFlow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer toflowFlow creation orflowFlow export time andwill referrefers to the Timestamp fields included in the samerecord.Data Record. This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) andit'sit is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID usingstructured data.IPFIX Structured Data [RFC6313]. Similarly, if differentmibCaptureTimeSemanticsMIB capture times apply to differentmibObjectmibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID usingstructured data.IPFIX Structured Data. Values:0.0 undefined1.1 begin - The value for the MIB object is captured from the MIB when the Flow is first observed2.2 end - The value for the MIB object is captured from the MIB when the Flow ends3.3 export - The value for the MIB object is captured from the MIB at export time4.4 average - The value for the MIB object is an average of multiple captures from the MIB over the observed life of the Flow Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId:TBD15448 Status: current Reference:[this document].RFC 8038 11.2.2.5. mibContextEngineID A new Information Element "mibContextEngineID"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: A mibContextEngineID that specifies the SNMP engine ID for a MIB field being exported over IPFIX. Definition as per[RFC3411] section 3.3[RFC3411], Section 3.3. Abstract Data Type: octetArray Data Type Semantics: default ElementId:TBD16449 Status: current Reference:[this document].RFC 8038 11.2.2.6. mibContextName A new Information Element "mibContextName"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description:ThisAn Information Element that denotes that a MIBContext Namecontext name is specified for a MIB field being exported over IPFIX. Reference[RFC3411] section 3.3[RFC3411], Section 3.3. Abstract Data Type: string Data Type Semantics: default ElementId:TBD17450 Status: current Reference:[this document].RFC 8038 11.2.3. New MIB Type Information Elements 11.2.3.1. mibObjectName A new Information Element "mibObjectName"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The name (called a descriptor in [RFC2578]) of an object type definition. Abstract Data Type: string Data Type Semantics: default ElementId:TBD18451 Status: current Reference:[this document].RFC 8038 11.2.3.2. mibObjectDescription A new Information Element "mibObjectDescription"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The value of the DESCRIPTION clause ofana MIB object type definition. Abstract Data Type: string Data Type Semantics: default ElementId:TBD19452 Status: current Reference:[this document].RFC 8038 11.2.3.3. mibObjectSyntax A new Information Element "mibObjectSyntax"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The value of the SYNTAX clause ofana MIB object type definition, which may include aTextual Conventiontextual convention orSubtyping.sub-typing. See [RFC2578]. Abstract Data Type: string Data Type Semantics: default ElementId:TBD20453 Status: current Reference:[this document].RFC 8038 11.2.3.4. mibModuleName A new Information Element "mibModuleName"must behas been allocated in IANA's IPFIX registry [IANA-IPFIX], with the following definition: Description: The textual name of the MIB module that defines a MIBObject.object. Abstract Data Type: string Data Type Semantics: default ElementId:TBD21454 Status: current Reference:[this document].RFC 8038 12.Acknowledgements 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. 13.References13.1.12.1. Normative References[BER] International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),International Organization for Standardization. International Standard 8825, December 1987", <http://www.iso.org>.[IANA-IPFIX] IANA,"IPFIX"IP Flow InformationElements registry", <http://www.iana.org/assignments/ipfix/ipfix.xml>. [IANA-IPFIX-SDTS] IANA, "IPFIX Structured Data Types Semantics registry", <http://www.iana.org/assignments/ipfix/ipfix.xml>.Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <http://www.rfc-editor.org/info/rfc2578>. [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, <http://www.rfc-editor.org/info/rfc2856>. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>. [RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, DOI 10.17487/RFC6526, March 2012, <http://www.rfc-editor.org/info/rfc6526>. [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>. [RFC7012] Claise, B.,Ed.Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.13.2.[X.690] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690>. 12.2. Informative References [CISCO-PROCESS-MIB] Cisco Systems Inc., "CISCO-PROCESS-MIB.my: MIB for CPU and process statistics",<http://tools.cisco.com/Support/SNMP/do/ BrowseMIB.do?local=en&mibName=CISCO-PROCESS-MIB>.<ftp://ftp.cisco.com/pub/mibs/v2/ CISCO-PROCESS-MIB.my>. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <http://www.rfc-editor.org/info/rfc2863>. [RFC2982] Kavasseri, R., Ed., "Distributed Management Expression MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000, <http://www.rfc-editor.org/info/rfc2982>. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, DOI 10.17487/RFC3415, December 2002, <http://www.rfc-editor.org/info/rfc3415>. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <http://www.rfc-editor.org/info/rfc3444>. [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, <http://www.rfc-editor.org/info/rfc4022>. [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, <http://www.rfc-editor.org/info/rfc4293>. [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006, <http://www.rfc-editor.org/info/rfc4750>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.[RFC5470] Sadasivan, G., Brownlee, N.,[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.Quittek, "ArchitectureMeyer, "Information Model for IP Flow Information Export", RFC5470,5102, DOI10.17487/RFC5470, March 2009, <http://www.rfc-editor.org/info/rfc5470>.10.17487/RFC5102, January 2008, <http://www.rfc-editor.org/info/rfc5102>. [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, March 2009, <http://www.rfc-editor.org/info/rfc5476>. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, <http://www.rfc-editor.org/info/rfc5591>. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 2009, <http://www.rfc-editor.org/info/rfc5592>. [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, <http://www.rfc-editor.org/info/rfc6235>. [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, <http://www.rfc-editor.org/info/rfc6313>. [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <http://www.rfc-editor.org/info/rfc6353>. Acknowledgments The authors would like to thank Andrew Johnson for his collaboration on the first draft version of this document, 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. Authors' Addresses Paul Aitken (editor) Brocade Communications Systems, Inc. 19a Canning Street, Level 3 Edinburgh, Scotland EH3 8EG United Kingdom Phone: +44 203 005 0731 Email: paitken@brocade.com Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Srikar B SCisco Systems,Mojo Networks, Inc.Mail Stop BGL13/3/, SEZ Unit, Cessna Business Park, Kadubeesanahalli Village Varthur Hobli, Sarjapur Marathalli Outer Ring Road Bangalore KARNATAKA 560 103 INS. No. 7, Pinnac House II Kothrud, Pune 411038 India Phone: +9180 4426 326494 4847 6672 Email:srikar@cisco.comsrikarbs@gmail.com Colin McDowall Brocade Communications Systems, Inc. 19a Canning Street, Level 3 Edinburgh, Scotland EH3 8EG United Kingdom Phone: +44 203 005 0687 Email: cmcdowal@brocade.com Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 Bremen 28725 Germany Phone: +49 421200-3587200 3587 Email: j.schoenwaelder@jacobs-university.de