summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5610.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5610.txt')
-rw-r--r--doc/rfc/rfc5610.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc5610.txt b/doc/rfc/rfc5610.txt
new file mode 100644
index 0000000..5825580
--- /dev/null
+++ b/doc/rfc/rfc5610.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group E. Boschi
+Request for Comments: 5610 B. Trammell
+Category: Standards Track Hitachi Europe
+ L. Mark
+ Fraunhofer IFAM
+ T. Zseby
+ Fraunhofer FOKUS
+ July 2009
+
+
+ Exporting Type Information for
+ IP Flow Information Export (IPFIX) Information Elements
+
+Abstract
+
+ This document describes an extension to the IP Flow Information
+ Export (IPFIX) protocol, which is used to represent and transmit data
+ from IP flow measurement devices for collection, storage, and
+ analysis, to allow the encoding of IPFIX Information Model properties
+ within an IPFIX Message stream. This enables the export of extended
+ type information for enterprise-specific Information Elements and the
+ storage of such information within IPFIX Files, facilitating
+ interoperability and reusability among a wide variety of applications
+ and tools.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 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 in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 1]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Type Information Export . . . . . . . . . . . . . . . . . . . 5
+ 3.1. informationElementDataType . . . . . . . . . . . . . . . . 5
+ 3.2. informationElementDescription . . . . . . . . . . . . . . 6
+ 3.3. informationElementName . . . . . . . . . . . . . . . . . . 7
+ 3.4. informationElementRangeBegin . . . . . . . . . . . . . . . 7
+ 3.5. informationElementRangeEnd . . . . . . . . . . . . . . . . 7
+ 3.6. informationElementSemantics . . . . . . . . . . . . . . . 8
+ 3.7. informationElementUnits . . . . . . . . . . . . . . . . . 9
+ 3.8. privateEnterpriseNumber . . . . . . . . . . . . . . . . . 9
+ 3.9. Information Element Type Options Template . . . . . . . . 10
+ 3.10. Data Type and Semantics Restrictions . . . . . . . . . . . 12
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
+ Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 2]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+1. Introduction
+
+ IP Flow Information Export (IPFIX) provides a template mechanism for
+ the flexible description of Data Records, by defining a record as a
+ collection of Information Elements defined in an IANA registry,
+ However, these Templates provide limited information about the type
+ of described data; indeed, they encode only the size of the fields
+ defined by these Information Elements. There presently exists no
+ mechanism to provide full type information for these Information
+ Elements, as is defined for the Information Elements in the IPFIX
+ Information Model [RFC5102].
+
+ This especially limits the interoperability of enterprise-specific
+ Information Elements. It is not possible to use analysis tools on
+ IPFIX records containing these partially defined Information Elements
+ that have not been developed with a priori knowledge of their types,
+ since such tools will not be able to decode them; these tools can
+ only treat and store them as opaque octet arrays. However, if richer
+ information is available, additional operations such as efficient
+ storage, display, and limited analysis of records containing
+ enterprise-specific Information Elements become possible, even for
+ Collecting Processes that have not been specifically developed to
+ understand them.
+
+ This document defines a general mechanism to encode the full set of
+ properties available for the definition of Information Elements
+ within the IPFIX Information Model inline within an IPFIX Message
+ stream using IPFIX Options. This mechanism may be used to fully
+ define type information for Information Elements used within a
+ message stream, without resorting to an external reference or
+ reliance on out-of-band configuration, thereby improving the
+ interoperability of enterprise-specific Information Elements.
+
+ Note that the solution described in this document is not intended as
+ a replacement for registration with IANA of generally useful
+ Information Elements. It introduces overhead and does not lead to
+ real interoperability as provided by standardization. Therefore, we
+ highly recommend standardizing all new generally useful Information
+ Elements by registering them with IANA. Standardization is
+ straightforward, and the type information that needs to be specified
+ in order to support the proposed solution provides a perfect basis
+ for the description required for standardizing the Information
+ Element.
+
+ It might happen that an Information Element previously described by
+ the mechanism in this document later becomes an IANA-registered,
+ standard Information Element. In such environments, old and new
+ versions of the Information Element can coexist. A translation
+
+
+
+Boschi, et al. Standards Track [Page 3]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ between Information Elements expressed by the described solution and
+ standardized Information Elements is therefore not necessary and is
+ out of scope for this document.
+
+1.1. IPFIX Documents Overview
+
+ "Specification of the IP Flow Information Export (IPFIX) Protocol for
+ the Exchange of IP Traffic Flow Information" [RFC5101] (informally,
+ the IPFIX Protocol document) and its associated documents define the
+ IPFIX Protocol, which provides network engineers and administrators
+ with access to IP traffic flow information.
+
+ "Architecture for IP Flow Information Export" [RFC5470] (the IPFIX
+ Architecture document) defines the architecture for the export of
+ measured IP flow information out of an IPFIX Exporting Process to an
+ IPFIX Collecting Process, and the basic terminology used to describe
+ the elements of this architecture, per the requirements defined in
+ "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX
+ Protocol document [RFC5101] then covers the details of the method for
+ transporting IPFIX Data Records and Templates via a congestion-aware
+ transport protocol from an IPFIX Exporting Process to an IPFIX
+ Collecting Process.
+
+ "Information Model for IP Flow Information Export" [RFC5102]
+ (informally, the IPFIX Information Model document) describes the
+ Information Elements used by IPFIX, including details on Information
+ Element naming, numbering, and data type encoding.
+
+ This document references the Protocol and Architecture documents for
+ terminology and extends the IPFIX Information Model to provide new
+ Information Elements for the representation of Information Element
+ properties. It draws data type definitions and data type semantics
+ definitions from the Information Model; the encodings of these data
+ types are defined in [RFC5101].
+
+2. Terminology
+
+ Terms used in this document that are defined in the Terminology
+ section of the IPFIX Protocol [RFC5101] document are to be
+ interpreted as defined there.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 4]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+3. Type Information Export
+
+ This section describes the mechanism used to encode Information
+ Element type information within an IPFIX Message stream. This
+ mechanism consists of an Options Template Record used to define
+ Information Element type records, and a set of Information Elements
+ required by these type records. We first specify the necessary
+ Information Elements, followed by the structure of the Options
+ Template describing the type records.
+
+ Note that Information Element type records require one Information
+ Element, informationElementId, that is defined in the Packet Sampling
+ (PSAMP) Information Model [RFC5477]. This Information Element
+ supports references only to IANA-defined Information Elements; the
+ privateEnterpriseNumber Information Element is required alongside
+ informationElementId to describe enterprise-specific Information
+ Elements.
+
+3.1. informationElementDataType
+
+ Description: A description of the abstract data type of an IPFIX
+ information element. These are taken from the abstract data types
+ defined in Section 3.1 of the IPFIX Information Model [RFC5102];
+ see that section for more information on the types described
+ below. This field may take the values defined in Table 1 below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 5]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ +-------+----------------------+
+ | Value | Description |
+ +-------+----------------------+
+ | 0 | octetArray |
+ | 1 | unsigned8 |
+ | 2 | unsigned16 |
+ | 3 | unsigned32 |
+ | 4 | unsigned64 |
+ | 5 | signed8 |
+ | 6 | signed16 |
+ | 7 | signed32 |
+ | 8 | signed64 |
+ | 9 | float32 |
+ | 10 | float64 |
+ | 11 | boolean |
+ | 12 | macAddress |
+ | 13 | string |
+ | 14 | dateTimeSeconds |
+ | 15 | dateTimeMilliseconds |
+ | 16 | dateTimeMicroseconds |
+ | 17 | dateTimeNanoseconds |
+ | 18 | ipv4Address |
+ | 19 | ipv6Address |
+ +-------+----------------------+
+
+ Table 1: IE Data Type Values
+
+ These types are registered in the IANA IPFIX Information Element
+ Data Type subregistry. This subregistry is intended to assign
+ numbers for type names, not to provide a mechanism for adding data
+ types to the IPFIX Protocol, and as such requires a Standards
+ Action [RFC5226] to modify.
+
+ Abstract Data Type: unsigned8
+
+ ElementId: 339
+
+ Status: current
+
+ Reference: Section 3.1 of the IPFIX Information Model [RFC5102]
+
+3.2. informationElementDescription
+
+ Description: A UTF-8 [RFC3629] encoded Unicode string containing a
+ human-readable description of an Information Element. The content
+ of the informationElementDescription MAY be annotated with one or
+ more language tags [RFC4646], encoded in-line [RFC2482] within the
+ UTF-8 string, in order to specify the language in which the
+
+
+
+Boschi, et al. Standards Track [Page 6]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ description is written. Description text in multiple languages
+ MAY tag each section with its own language tag; in this case, the
+ description information in each language SHOULD have equivalent
+ meaning. In the absence of any language tag, the "i-default"
+ [RFC2277] language SHOULD be assumed. See the Security
+ Considerations (Section 4) for notes on string handling for
+ Information Element type records.
+
+ Abstract Data Type: string
+
+ ElementId: 340
+
+ Status: current
+
+3.3. informationElementName
+
+ Description: A UTF-8 [RFC3629] encoded Unicode string containing
+ the name of an Information Element, intended as a simple
+ identifier. See the Security Considerations (Section 4) for notes
+ on string handling for Information Element type records.
+
+ Abstract Data Type: string
+
+ ElementId: 341
+
+ Status: current
+
+3.4. informationElementRangeBegin
+
+ Description: Contains the inclusive low end of the range of
+ acceptable values for an Information Element.
+
+ Abstract Data Type: unsigned64
+
+ Data Type Semantics: quantity
+
+ ElementId: 342
+
+ Status: current
+
+3.5. informationElementRangeEnd
+
+ Description: Contains the inclusive high end of the range of
+ acceptable values for an Information Element.
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 7]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ Abstract Data Type: unsigned64
+
+ Data Type Semantics: quantity
+
+ ElementId: 343
+
+ Status: current
+
+3.6. informationElementSemantics
+
+ Description: A description of the semantics of an IPFIX Information
+ Element. These are taken from the data type semantics defined in
+ Section 3.2 of the IPFIX Information Model [RFC5102]; see that
+ section for more information on the types described below. This
+ field may take the values in Table 2 below. The special value
+ 0x00 (default) is used to note that no semantics apply to the
+ field; it cannot be manipulated by a Collecting Process or File
+ Reader that does not understand it a priori.
+
+ +-------+--------------+
+ | Value | Description |
+ +-------+--------------+
+ | 0 | default |
+ | 1 | quantity |
+ | 2 | totalCounter |
+ | 3 | deltaCounter |
+ | 4 | identifier |
+ | 5 | flags |
+ +-------+--------------+
+
+ Table 2: IE Semantics Values
+
+ These semantics are registered in the IANA IPFIX Information
+ Element Semantics subregistry. This subregistry is intended to
+ assign numbers for semantics names, not to provide a mechanism for
+ adding semantics to the IPFIX Protocol, and as such requires a
+ Standards Action [RFC5226] to modify.
+
+ Abstract Data Type: unsigned8
+
+ ElementId: 344
+
+ Status: current
+
+ Reference: Section 3.2 of the IPFIX Information Model [RFC5102]
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 8]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+3.7. informationElementUnits
+
+ Description: A description of the units of an IPFIX Information
+ Element. These correspond to the units implicitly defined in the
+ Information Element definitions in Section 5 of the IPFIX
+ Information Model [RFC5102]; see that section for more information
+ on the types described below. This field may take the values in
+ Table 3 below; the special value 0x00 (none) is used to note that
+ the field is unitless.
+
+ +-------+---------------+---------------------------+
+ | Value | Name | Notes |
+ +-------+---------------+---------------------------+
+ | 0 | none | |
+ | 1 | bits | |
+ | 2 | octets | |
+ | 3 | packets | |
+ | 4 | flows | |
+ | 5 | seconds | |
+ | 6 | milliseconds | |
+ | 7 | microseconds | |
+ | 8 | nanoseconds | |
+ | 9 | 4-octet words | for IPv4 header length |
+ | 10 | messages | for reliability reporting |
+ | 11 | hops | for TTL |
+ | 12 | entries | for MPLS label stack |
+ +-------+---------------+---------------------------+
+
+ Table 3: IE Units Values
+
+ These types are registered in the IANA IPFIX Information Element
+ Units subregistry; new types may be added on a First Come First
+ Served [RFC5226] basis.
+
+ Abstract Data Type: unsigned16
+
+ ElementId: 345
+
+ Status: current
+
+ Reference: Section 5 of the IPFIX Information Model [RFC5102]
+
+3.8. privateEnterpriseNumber
+
+ Description: A private enterprise number, as assigned by IANA.
+ Within the context of an Information Element Type record, this
+ element can be used along with the informationElementId element to
+ scope properties to a specific Information Element. To export
+
+
+
+Boschi, et al. Standards Track [Page 9]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ type information about an IANA-assigned Information Element, set
+ the privateEnterpriseNumber to 0, or do not export the
+ privateEnterpriseNumber in the type record. To export type
+ information about an enterprise-specific Information Element,
+ export the enterprise number in privateEnterpriseNumber, and
+ export the Information Element number with the Enterprise bit
+ cleared in informationElementId. The Enterprise bit in the
+ associated informationElementId Information Element MUST be
+ ignored by the Collecting Process.
+
+ Abstract Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ ElementId: 346
+
+ Status: current
+
+ Reference: Sections 3.2 and 3.4.1 of the IPFIX Protocol [RFC5101];
+ Section 8.2.3 of the PSAMP Information Model [RFC5477].
+
+3.9. Information Element Type Options Template
+
+ The Information Element Type Options Template attaches type
+ information to Information Elements used within Template Records, as
+ scoped to an Observation Domain within a Transport Session. This
+ provides a mechanism for representing an IPFIX Information Model
+ inline within an IPFIX Message stream. Data Records described by
+ this template are referred to as Information Element type records.
+
+ In deployments in which interoperability across vendor
+ implementations of IPFIX is important, an Exporting Process exporting
+ data using Templates containing enterprise-specific Information
+ Elements SHOULD export an Information Element type record for each
+ enterprise-specific Information Element it exports. Collecting
+ Processes MAY use these type records to improve handling of unknown
+ enterprise-specific Information Elements. Exporting Processes using
+ enterprise-specific Information Elements to implement proprietary
+ features MAY omit type records for those Information Elements.
+
+ Information Element type records MUST be handled by Collecting
+ Processes as scoped to the Transport Session in which they are sent;
+ this facility is not intended to provide a method for the permanent
+ definition of Information Elements.
+
+ Similarly, for security reasons, type information for a given
+ Information Element MUST NOT be redefined by Information Element type
+ records, and a Collecting Process MUST NOT allow an Information
+
+
+
+Boschi, et al. Standards Track [Page 10]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ Element type record to replace its own internal definition of an
+ Information Element. Information Element type records SHOULD NOT be
+ duplicated in a given Observation Domain within a Transport Session.
+ Once an Information Element type record has been exported for a given
+ Information Element within a given Transport Session, all subsequent
+ type records for that Information Element MUST be identical.
+ Information Elements for which a Collecting Process receives
+ conflicting semantic or type information MUST be ignored.
+
+ Note that while this template MAY be used to export information about
+ any Information Element, including those registered with IANA,
+ Exporting Processes SHOULD NOT export any type records that could be
+ reasonably assumed to duplicate type information available at the
+ Collecting Process. This mechanism is not intended as a replacement
+ for Exporting and Collecting Processes keeping up to date with
+ changes to the IANA registry; such an update mechanism is out of
+ scope for this document.
+
+ The template SHOULD contain the Information Elements in Table 4,
+ below, as defined in the PSAMP Information Model [RFC5477] and in
+ this document, above.
+
+ +-------------------------------+-----------------------------------+
+ | IE | Description |
+ +-------------------------------+-----------------------------------+
+ | informationElementId [scope] | The Information Element |
+ | | identifier of the Information |
+ | | Element described by this type |
+ | | record. This Information Element |
+ | | MUST be defined as a Scope Field. |
+ | | See the PSAMP Information Model |
+ | | [RFC5477] for a definition of |
+ | | this field. |
+ | privateEnterpriseNumber | The Private Enterprise number of |
+ | [scope] | the Information Element described |
+ | | by this type record. This |
+ | | Information Element MUST be |
+ | | defined as a Scope Field. |
+ | informationElementDataType | The storage type of the specified |
+ | | Information Element. |
+ | informationElementSemantics | The semantic type of the |
+ | | specified Information Element. |
+ | informationElementUnits | The units of the specified |
+ | | Information Element. This |
+ | | element SHOULD be omitted if the |
+ | | Information Element is a unitless |
+ | | quantity, or a not a quantity or |
+ | | counter. |
+
+
+
+Boschi, et al. Standards Track [Page 11]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ +-------------------------------+-----------------------------------+
+ | IE (Continued) | Description (Continued) |
+ +-------------------------------+-----------------------------------+
+ | informationElementRangeBegin | The low end of the range of |
+ | | acceptable values for the |
+ | | specified Information Element. |
+ | | This element SHOULD be omitted if |
+ | | the beginning of the Information |
+ | | Element's acceptable range is |
+ | | defined by its data type. |
+ | informationElementRangeEnd | The high end of the range of |
+ | | acceptable values for the |
+ | | specified Information Element. |
+ | | This element SHOULD be omitted if |
+ | | the end Information Element's |
+ | | acceptable range is defined by |
+ | | its data type. |
+ | informationElementName | The name of the specified |
+ | | Information Element. |
+ | informationElementDescription | A human-readable description of |
+ | | the specified Information |
+ | | Element. This element MAY be |
+ | | omitted in the interest of export |
+ | | efficiency. |
+ +-------------------------------+-----------------------------------+
+
+ Table 4: IE Type Options
+
+3.10. Data Type and Semantics Restrictions
+
+ Note that the informationElementSemantics values defined in Section
+ 3.2 of [RFC5102] are primarily intended to differentiate semantic
+ interpretation of numeric values, and that not all combinations of
+ the informationElementDataType and informationElementSemantics
+ Information Elements are valid; e.g., a counter cannot be encoded as
+ an IPv4 address. The following are acceptable values of
+ informationElementSemantics:
+
+ o Any value is valid for unsigned informationElementDataType values
+ ("unsigned8", "unsigned16", "unsigned32", or "unsigned64").
+
+ o Any value except "flags" is valid for signed
+ informationElementDataType values ("signed8", "signed16",
+ "signed32", or "signed64").
+
+ o Any value except "identifier" or "flags" is valid for floating-
+ point informationElementDataType values ("float32" or "float64").
+
+
+
+
+Boschi, et al. Standards Track [Page 12]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ o Only "default" is valid for all other informationElementDataType
+ values ("octetArray", "boolean", "macAddress", "string",
+ "dateTimeSeconds", "dateTimeMilliseconds", "dateTimeMicroseconds",
+ "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").
+
+ Information Element type records containing invalid combinations of
+ informationElementSemantics and informationElementDataType MUST NOT
+ be sent by Exporting Processes, and MUST be ignored by Collecting
+ Processes.
+
+ Future Standards Actions that modify the Information Element Data
+ Type subregistry or the Information Element Semantics subregistry
+ should contain a Data Type and Semantics Restrictions section such as
+ this one to define allowable combinations of type and semantics
+ information.
+
+4. Security Considerations
+
+ The same security considerations as for the IPFIX Protocol [RFC5101]
+ apply.
+
+ In addition, attention must be paid to the handling of Information
+ Element type records at the Collecting Process. Type information
+ precedence rules defined above (a Collecting Process' current
+ knowledge overrides type records; types are not redefinable during a
+ session) are designed to minimize the opportunity for an attacker to
+ maliciously redefine the data model.
+
+ Note that Information Element type records may contain two strings
+ describing Information Elements: informationElementName and
+ informationElementDescription. IPFIX strings on the wire are length-
+ prefixed and UTF-8 [RFC3629] encoded, most often within an IPFIX
+ variable-length Information Element, which mitigates the risk of
+ unterminated-string attacks against IPFIX Collecting Processes.
+ However, care should still be taken when handling strings within the
+ type system of the Collecting Process.
+
+ First, Collecting Processes should pay particular attention to buffer
+ sizes converting between length-prefixed and null-terminated strings.
+ Exporting Processes MUST NOT export, and Collecting Processes MUST
+ ignore, any informationElementName or informationElementDescription
+ content that contains null characters (U+0000) in order to ensure
+ buffer and string lengths are consistent.
+
+ Also, note that there is no limit to IPFIX string length beyond that
+ inherent in the protocol. The maximum IPFIX string length is 65512
+ octets (maximum message length (65535), minus message header (16),
+ minus set header (4), minus long variable length field (3)).
+
+
+
+Boschi, et al. Standards Track [Page 13]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ Specifically, although the informationElementName of all IANA
+ Information Elements at the time of this writing is less than about
+ 40 octets, and the informationElementDescription is less than 4096
+ octets, either of these Information Elements may contain strings up
+ to 65512 octets long.
+
+5. IANA Considerations
+
+ This document specifies several new IPFIX Information Elements in the
+ IPFIX Information Element registry as defined in Section 3 above.
+ IANA has assigned the following Information Element numbers for their
+ respective Information Elements as specified below:
+
+ o Information Element Number 339 for the informationElementDataType
+ Information Element
+
+ o Information Element Number 340 for the
+ informationElementDescription Information Element
+
+ o Information Element Number 341 for the informationElementName
+ Information Element
+
+ o Information Element Number 342 for the
+ informationElementRangeBegin Information Element
+
+ o Information Element Number 343 for the informationElementRangeEnd
+ Information Element
+
+ o Information Element Number 344 for the informationElementSemantics
+ Information Element
+
+ o Information Element Number 345 for the informationElementUnits
+ Information Element
+
+ o Information Element Number 346 for the privateEnterpriseNumber
+ Information Element
+
+ IANA has created an Information Element Data Type subregistry for the
+ values defined for the informationElementDataType Information
+ Element. Entries may be added to this subregistry subject to a
+ Standards Action [RFC5226].
+
+ IANA has created an Information Element Semantics subregistry for the
+ values defined for the informationElementSemantics Information
+ Element. Entries may be added to this subregistry subject to a
+ Standards Action [RFC5226].
+
+
+
+
+
+Boschi, et al. Standards Track [Page 14]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ IANA has created an Information Element Units subregistry for the
+ values defined for the informationElementUnits Information Element.
+ Entries may be added to this subregistry on an Expert Review
+ [RFC5226] basis.
+
+6. Acknowledgements
+
+ Thanks to Paul Aitken and Gerhard Muenz for the detailed reviews, and
+ to David Moore for first raising this issue to the IPFIX mailing
+ list. Thanks to the PRISM project for its support of this work.
+
+7. References
+
+7.1. Normative References
+
+ [RFC5101] Claise, B., "Specification of the IP Flow Information
+ Export (IPFIX) Protocol for the Exchange of IP Traffic
+ Flow Information", RFC 5101, January 2008.
+
+ [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
+ Meyer, "Information Model for IP Flow Information Export",
+ RFC 5102, January 2008.
+
+ [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
+ Carle, "Information Model for Packet Sampling Exports",
+ RFC 5477, March 2009.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", BCP 18, RFC 2277, January 1998.
+
+ [RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode
+ Plain Text", RFC 2482, January 1999.
+
+ [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 4646, September 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 15]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+7.2. Informative References
+
+ [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
+ "Requirements for IP Flow Information Export (IPFIX)",
+ RFC 3917, October 2004.
+
+ [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+ "Architecture for IP Flow Information Export", RFC 5470,
+ March 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 16]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+Appendix A. Examples
+
+ The following example illustrates how the type information extension
+ mechanism defined in this document may be used to describe the
+ semantics of enterprise-specific Information Elements. The
+ Information Elements used in this example are as follows:
+
+ o initialTCPFlags, an example private IE 14, 1 octet, the TCP flags
+ on the first TCP packet in the flow.
+
+ o unionTCPFlags, an example private IE 15, 1 octet, the union of the
+ TCP flags on all packets after the first TCP packet in the flow.
+
+ An Exporting Process exporting flows containing these Information
+ Elements might use a Template like the following:
+
+ 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 = 52 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Template ID = 256 | Field Count = 9 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| flowStartSeconds 150 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| sourceIPv4Address 8 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| destinationIPv4Address 12 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| sourceTransportPort 7 | Field Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| destinationTransportPort 11 | Field Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| octetTotalCount 85 | Field Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| (initialTCPFlags) 14 | Field Length = 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Private Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |1| (unionTCPFlags) 15 | Field Length = 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Private Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| protocolIdentifier 4 | Field Length = 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Template with Enterprise-Specific IEs
+
+
+
+
+Boschi, et al. Standards Track [Page 17]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ However, a Collecting Process receiving Data Sets described by this
+ Template can only treat the enterprise-specific Information Elements
+ as opaque octets; specifically, there is no hint to the collector
+ that they contain flag information. To use the type information
+ extension mechanism to address this problem, the Exporting Process
+ would first export the Information Element Type Options Template
+ described in Section 3.9 above:
+
+ 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 = 257 | Field Count = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Scope Field Count = 2 |0| priv.EnterpriseNumber 346 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 4 |0| informationElementId 303 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 2 |0| inf.El.DataType 339 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 1 |0| inf.El.Semantics 344 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 1 |0| inf.El.Name 341 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Field Length = 65536 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2: Example Information Element Type Options Template
+
+ Then, the Exporting Process would export two records described by the
+ Example Information Element Type Options Template to describe the
+ enterprise-specific Information Elements:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 18]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Set ID = 257 | Length = 50 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Private Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |X| IE 14 |0x01 unsigned8 |0x05 flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 15 length | |
+ +-+-+-+-+-+-+-+-+ |
+ | "initialTCPFlags" |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Private Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |X| IE 15 |0x01 unsigned8 |0x05 flags |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 13 length | |
+ +-+-+-+-+-+-+-+-+ "unionTCPFlags" |
+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Type Record Example
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 19]
+
+RFC 5610 IPFIX Type Information July 2009
+
+
+Authors' Addresses
+
+ Elisa Boschi
+ Hitachi Europe
+ c/o ETH Zurich
+ Gloriastrasse 35
+ 8092 Zurich
+ Switzerland
+
+ Phone: +41 44 632 70 57
+ EMail: elisa.boschi@hitachi-eu.com
+
+
+ Brian Trammell
+ Hitachi Europe
+ c/o ETH Zurich
+ Gloriastrasse 35
+ 8092 Zurich
+ Switzerland
+
+ Phone: +41 44 632 70 13
+ EMail: brian.trammell@hitachi-eu.com
+
+
+ Lutz Mark
+ Fraunhofer Institute for Manufacturing Technology
+ and Applied Materials Research
+ Wiener Str. 12
+ 28359 Bremen
+ Germany
+
+ Phone: +49 421 2246206
+ EMail: lutz.mark@ifam.fraunhofer.de
+
+
+ Tanja Zseby
+ Fraunhofer Institute for Open Communication Systems
+ Kaiserin-Augusta-Allee 31
+ 10589 Berlin
+ Germany
+
+ Phone: +49 30 3463 7153
+ EMail: tanja.zseby@fokus.fraunhofer.de
+
+
+
+
+
+
+
+
+Boschi, et al. Standards Track [Page 20]
+