idnits 2.17.1 draft-ietf-ipfix-information-model-rfc5102bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2012) is 4476 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-protocol-rfc5101bis-00 -- Possible downref: Normative reference to a draft: ref. 'RFC5101bis' == Outdated reference: A later version (-07) exists of draft-ietf-ipfix-ie-doctors-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5102 (ref. 'RFC5103') (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-ipfix-configuration-model-10 == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-00 == Outdated reference: A later version (-03) exists of draft-ietf-ipfix-rfc5815bis-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Obsoletes: 5102 B. Trammell, Ed. 5 Category: Standards Track ETH Zurich 6 Expires: July 27, 2012 January 24, 2012 8 Information Model for IP Flow Information eXport (IPFIX) 9 draft-ietf-ipfix-information-model-rfc5102bis-00.txt 11 Abstract 13 This memo defines an overview of the information model for the IP Flow 14 Information eXport (IPFIX) protocol. It is used by the IPFIX protocol 15 for encoding measured traffic information and information related to the 16 traffic Observation Point, the traffic Metering Process, and the 17 Exporting Process. Although developed for the IPFIX protocol, the model 18 is defined in an open way that easily allows using it in other 19 protocols, interfaces, and applications. This document obsoletes RFC 20 5102. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 23, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Changes since RFC 5102 . . . . . . . . . . . . . . . . . . 4 58 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 59 2. Properties of IPFIX Protocol Information Elements . . . . . . 5 60 2.1. Information Elements Specification Template . . . . . . . 5 61 2.2. Scope of Information Elements . . . . . . . . . . . . . . 7 62 2.3. Naming Conventions for Information Elements . . . . . . . 7 63 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 8 65 3.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.6. signed16 . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.7. signed32 . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.8. signed64 . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.11. boolean . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.12. macAddress . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.13. octetArray . . . . . . . . . . . . . . . . . . . . . 10 78 3.1.14. string . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.15. dateTimeSeconds . . . . . . . . . . . . . . . . . . . 10 80 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 10 81 3.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . . . 10 82 3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 10 83 3.1.19. ipv4Address . . . . . . . . . . . . . . . . . . . . . 11 84 3.1.20. ipv6Address . . . . . . . . . . . . . . . . . . . . . 11 85 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 86 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 11 88 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 11 89 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 90 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4. Information Element Identifiers . . . . . . . . . . . . . . . 12 92 5. Information Elements . . . . . . . . . . . . . . . . . . . . . 16 93 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.3. Metering and Exporting Process Statistics . . . . . . . . 19 95 5.4. IP Header Fields . . . . . . . . . . . . . . . . . . . . . 19 96 5.5. Transport Header Fields . . . . . . . . . . . . . . . . . 20 97 5.6. Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 21 98 5.7. Derived Packet Properties . . . . . . . . . . . . . . . . 21 99 5.9. Flow Timestamps . . . . . . . . . . . . . . . . . . . . . 21 100 5.10. Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 22 101 5.11. Miscellaneous Flow Properties . . . . . . . . . . . . . . 23 102 5.12. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 6. Extending the Information Model . . . . . . . . . . . . . . . 24 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 105 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 24 106 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 25 107 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 25 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 112 10.2. Informative References . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 115 OPEN ISSUES: 117 * "revision", "date", "enterprise-specific" added from [IPFIX-IE- 118 DOCTORS]. So we need to change the section 2.1. Harmonize with IE- 119 DOCTORS section 12. 121 * Do we want to have a new column in IANA for the max length for 122 string, arrary, and potentially others? DISCUSSION on the mailing 123 list 125 Clarified the dateTimeSeconds and dateTimeMilliseconds. "excluding 126 leap seconds" in the current definition is not clear according to 127 Paul Aitken. 129 1. Introduction 131 The IP Flow Information eXport (IPFIX) protocol serves for 132 transmitting information related to measured IP traffic over the 133 Internet. The protocol specification in [RFC5101bis] defines how 134 Information Elements are transmitted. For Information Elements, it 135 specifies the encoding of a set of basic data types. However, the 136 list of Information Elements that can be transmitted by the protocol, 137 such as Flow attributes (source IP address, number of packets, etc.) 138 and information about the Metering and Exporting Process (packet 139 Observation Point, sampling rate, Flow timeout interval, etc.), is 140 not specified in [RFC5101bis]. 142 This document complements the IPFIX protocol specification by 143 providing an overview of the IPFIX information model and specifying 144 data types for it. IPFIX-specific terminology used in this document 145 is defined in Section 2 of [RFC5101bis]. As in [RFC5101bis], these 146 IPFIX-specific terms have the first letter of a word capitalized when 147 used in this document. 149 The use of the term 'information model' is not fully in line with the 150 definition of this term in [RFC3444]. The IPFIX information model 151 does not specify relationships between Information Elements, but also 152 it does not specify a concrete encoding of Information Elements. 153 Besides the encoding used by the IPFIX protocol, other encodings of 154 IPFIX Information Elements can be applied, for example, XML-based 155 encodings. 157 The main part of this document is Section 5, which displays some of 158 Information Elements to be transmitted by the IPFIX protocol. 159 Section 2 defines a template for specifying IPFIX Information 160 Elements in Section 5. Section 3 defines the set of abstract data 161 types that are available for IPFIX Information Elements. Section 6 162 discusses extensibility of the IPFIX information model. 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 1.1. Changes since RFC 5102 170 This document obsoletes the Proposed Standard revision of the IPFIX 171 Protocol Specification [RFC5102]. The following changes have been 172 made to this document with respect to the previous document: 174 - EDITOR'S NOTE: not sure if we need to this information 175 Errata ID: 1307 (technical) 176 Errata ID: 1492 (technical) 177 Errata ID: 1736 (technical) 178 Errata ID: 2879 (editorial) 179 Errata ID: 2944, which updates 1737 (technical) 180 Errata ID: 2945, which updates 1738 (technical) 181 Errata ID: 2946, which updates 1739 (technical) 182 Updated the reference to RFC5101bis 183 Clarified the time-related IEs 185 - Since this document is based on the IPFIX Draft Standard 186 [RFC5101bis], all improvements have been taken into account. For 187 example, the timestamps.- Instead of repeating every Information 188 Elements from [RFC5102], a reference to the IPFIX IANA registry 189 [IPFIX-IANA] is introduced. However the category in section 5 have 190 been kept.- The appendix A and B have been removed- Introduced 191 [IPFIX-IE-DOCTORS] 193 1.2. IPFIX Documents Overview 195 The IPFIX protocol provides network administrators with access to IP 196 flow information. The architecture for the export of measured IP 197 flow information out of an IPFIX Exporting Process to a Collecting 198 Process is defined in [RFC5470], per the requirements defined in 199 [RFC3917]. The IPFIX specifications [RFC5101bis] document specifies 200 how IPFIX data records and templates are carried via a number of 201 transport protocols from IPFIX Exporting Processes to IPFIX 202 Collecting Processes. 204 Four IPFIX optimizations/extensions are currently specified: a 205 bandwidth saving method for the IPFIX protocol in [RFC5473], an 206 efficient method for exporting bidirectional flow in [RFC5103], a 207 method for the definition and export of complex data structures in 208 [RFC6313], and the specification of the Protocol for IPFIX Mediations 209 [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. 211 IPFIX has a formal description of IPFIX Information Elements, their 212 name, type and additional semantic information, as specified in this 213 document, with the export of the Information Element types specified 214 in [RFC5610]. 216 [IPFIX-CONF] specifies a data model for configuring and monitoring 217 IPFIX and PSAMP compliant devices using the NETCONF protocol, while 218 the [RFC5815bis] specifies a MIB module for monitoring. 220 In terms of development, [RFC5153] provides guidelines for the 221 implementation and use of the IPFIX protocol, while [RFC5471] 222 provides guidelines for testing. 224 Finally, [RFC5472] describes what type of applications can use the 225 IPFIX protocol and how they can use the information provided. It 226 furthermore shows how the IPFIX framework relates to other 227 architectures and frameworks. 229 2. Properties of IPFIX Protocol Information Elements 231 2.1. Information Elements Specification Template 233 Information in messages of the IPFIX protocol is modeled in terms of 234 Information Elements of the IPFIX information model. The IPFIX 235 Information Elements mentioned in Section 5 are specified in [IPFIX- 236 IANA]. For specifying these Information Elements, a template is used 237 that is described below. 239 All Information Elements specified for the IPFIX protocol either in 240 this document or by any future extension MUST have the following 241 properties defined: 243 name - A unique and meaningful name for the Information Element. 245 elementId - A numeric identifier of the Information Element. If this 246 identifier is used without an enterprise identifier (see 247 [RFC5101bis] and enterpriseId below), then it is globally unique 248 and the list of allowed values is administered by IANA. It is 249 used for compact identification of an Information Element when 250 encoding Templates in the protocol. 252 description - The semantics of this Information Element. Describes 253 how this Information Element is derived from the Flow or other 254 information available to the observer. 256 dataType - One of the types listed in Section 3.1 of this document or 257 in a future extension of the information model. The type space 258 for attributes is constrained to facilitate implementation. The 259 existing type space does however encompass most basic types used 260 in modern programming languages, as well as some derived types 261 (such as ipv4Address) that are common to this domain and useful to 262 distinguish. 264 status - The status of the specification of this Information Element. 265 Allowed values are 'current', 'deprecated', and 'obsolete'. 267 Enterprise-specific Information Elements MUST have the following 268 property defined: 270 enterpriseId - Enterprises may wish to define Information Elements 271 without registering them with IANA, for example, for 272 enterprise-internal purposes. For such Information Elements, the 273 Information Element identifier described above is not sufficient 274 when the Information Element is used outside the enterprise. If 275 specifications of enterprise-specific Information Elements are 276 made public and/or if enterprise-specific identifiers are used by 277 the IPFIX protocol outside the enterprise, then the 278 enterprise-specific identifier MUST be made globally unique by 279 combining it with an enterprise identifier. Valid values for the 280 enterpriseId are defined by IANA as Structure of Management 281 Information (SMI) network management private enterprise codes. 282 They are defined at http://www.iana.org/assignments/enterprise- 283 numbers. 285 All Information Elements specified for the IPFIX protocol either in 286 this document or by any future extension MAY have the following 287 properties defined: 289 dataTypeSemantics - The integral types may be qualified by additional 290 semantic details. Valid values for the data type semantics are 291 specified in Section 3.2 of this document or in a future extension 292 of the information model. 294 units - If the Information Element is a measure of some kind, the 295 units identify what the measure is. 297 range - Some Information Elements may only be able to take on a 298 restricted set of values that can be expressed as a range (e.g., 0 299 through 511 inclusive). If this is the case, the valid inclusive 300 range should be specified. 302 reference - Identifies additional specifications that more precisely 303 define this item or provide additional context for its use. 305 2.2. Scope of Information Elements 307 By default, most Information Elements have a scope specified in their 308 definitions. 310 o The Information Elements defined in Sections 5.2 and 5.3 have a 311 default of "a specific Metering Process" or of "a specific 312 Exporting Process", respectively. 314 o The Information Elements defined in Sections 5.4-5.11 have a scope 315 of "a specific Flow". 317 Within Data Records defined by Option Templates, the IPFIX protocol 318 allows further limiting of the Information Element scope. The new 319 scope is specified by one or more scope fields and defined as the 320 combination of all specified scope values; see Section 3.4.2.1 on 321 IPFIX scopes in [RFC5101bis]. 323 2.3. Naming Conventions for Information Elements 325 The following naming conventions were used for naming Information 326 Elements in this document. It is recommended that extensions of the 327 model use the same conventions. 329 o Names of Information Elements should be descriptive. 331 o Names of Information Elements that are not enterprise-specific 332 MUST be unique within the IPFIX information model. 334 Enterprise-specific Information Elements SHOULD be prefixed with a 335 vendor name. 337 o Names of Information Elements start with non-capitalized letters. 339 o Composed names use capital letters for the first letter of each 340 component (except for the first one). All other letters are 341 non-capitalized, even for acronyms. Exceptions are made for 342 acronyms containing non-capitalized letter, such as 'IPv4' and 343 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address. 345 o Middleboxes [RFC3234] may change Flow properties, such as the 346 Differentiated Service Code Point (DSCP) value or the source IP 347 address. If an IPFIX Observation Point is located in the path of 348 a Flow before one or more middleboxes that potentially modify 349 packets of the Flow, then it may be desirable to also report Flow 350 properties after the modification performed by the middleboxes. 351 An example is an Observation Point before a packet marker changing 352 a packet's IPv4 Type of Service (TOS) field that is encoded in 353 Information Element ipClassOfService. Then the value observed and 354 reported by Information Element ipClassOfService is valid at the 355 Observation Point, but not after the packet passed the packet 356 marker. For reporting the change value of the TOS field, the 357 IPFIX information model uses Information Elements that have a name 358 prefix "post", for example, "postIpClassOfService". Information 359 Elements with prefix "post" report on Flow properties that are not 360 necessarily observed at the Observation Point, but which are 361 obtained within the Flow's Observation Domain by other means 362 considered to be sufficiently reliable, for example, by analyzing 363 the packet marker's marking tables. 365 3. Type Space 367 This section describes the abstract data types that can be used for 368 the specification of IPFIX Information Elements in Section 4. 369 Section 3.1 describes the set of abstract data types. 371 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, 372 signed8, signed16, signed32, and signed64 are integral data types. 373 As described in Section 3.2, their data type semantics can be further 374 specified, for example, by 'totalCounter', 'deltaCounter', 375 'identifier', or 'flags'. 377 3.1. Abstract Data Types 379 This section describes the set of valid abstract data types of the 380 IPFIX information model. Note that further abstract data types may 381 be specified by future extensions of the IPFIX information model. 383 3.1.1. unsigned8 385 The type "unsigned8" represents a non-negative integer value in the 386 range of 0 to 255. 388 3.1.2. unsigned16 390 The type "unsigned16" represents a non-negative integer value in the 391 range of 0 to 65535. 393 3.1.3. unsigned32 395 The type "unsigned32" represents a non-negative integer value in the 396 range of 0 to 4294967295. 398 3.1.4. unsigned64 400 The type "unsigned64" represents a non-negative integer value in the 401 range of 0 to 18446744073709551615. 403 3.1.5. signed8 405 The type "signed8" represents an integer value in the range of -128 406 to 127. 408 3.1.6. signed16 410 The type "signed16" represents an integer value in the range of 411 -32768 to 32767. 413 3.1.7. signed32 415 The type "signed32" represents an integer value in the range of 416 -2147483648 to 2147483647. 418 3.1.8. signed64 420 The type "signed64" represents an integer value in the range of 421 -9223372036854775808 to 9223372036854775807. 423 3.1.9. float32 425 The type "float32" corresponds to an IEEE single-precision 32-bit 426 floating point type as defined in [IEEE.754.1985]. 428 3.1.10. float64 430 The type "float64" corresponds to an IEEE double-precision 64-bit 431 floating point type as defined in [IEEE.754.1985]. 433 3.1.11. boolean 435 The type "boolean" represents a binary value. The only allowed 436 values are "true" and "false". 438 3.1.12. macAddress 440 The type "macAddress" represents a string of 6 octets. 442 3.1.13. octetArray 444 The type "octetArray" represents a finite-length string of octets. 446 3.1.14. string 448 The type "string" represents a finite-length string of valid 449 characters from the Unicode character encoding set 450 [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many 451 other international character sets to be used. 453 3.1.15. dateTimeSeconds 455 The type "dateTimeSeconds" represents a time value in units of 456 seconds since the UNIX epoch, 1 January 1970 at 00:00 coordinated 457 universal time (UTC), excluding leap seconds. 459 3.1.16. dateTimeMilliseconds 461 The type "dateTimeSeconds" represents a time value in units of 462 milliseconds since the UNIX epoch, 1 January 1970 at 00:00 463 coordinated universal time (UTC), excluding leap seconds. 465 3.1.17. dateTimeMicroseconds 467 The type "dateTimeMicroseconds" represents a time value with 468 microsecond precision according to the NTP Timestamp format as 469 defined in section 6 of [RFC5905]. This field is made up of two 470 unsigned 32-bit integers, Seconds and Fraction. The Seconds field is 471 the number of seconds since the NTP epoch, 1 January 1900 at 00:00 472 UTC. The Fraction field is the fractional number of seconds in units 473 of 1/(2^32) seconds (approximately 233 picoseconds). 475 3.1.18. dateTimeNanoseconds 477 The type "dateTimeMicroseconds" represents a time value with 478 nanosecond precision according to the NTP Timestamp format as defined 479 in section 6 of [RFC5905]. This field is made up of two unsigned 32- 480 bit integers, Seconds and Fraction. The Seconds field is the number 481 of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The 482 Fraction field is the fractional number of seconds in units of 483 1/(2^32) seconds (approximately 233 picoseconds). 485 3.1.19. ipv4Address 487 The type "ipv4Address" represents a value of an IPv4 address. 489 3.1.20. ipv6Address 491 The type "ipv6Address" represents a value of an IPv6 address. 493 3.2. Data Type Semantics 495 This section describes the set of valid data type semantics of the 496 IPFIX information model. Note that further data type semantics may 497 be specified by future extensions of the IPFIX information model. 499 3.2.1. quantity 501 A quantity value represents a discrete measured value pertaining to 502 the record. This is distinguished from counters that represent an 503 ongoing measured value whose "odometer" reading is captured as part 504 of a given record. If no semantic qualifier is given, the 505 Information Elements that have an integral data type should behave as 506 a quantity. 508 3.2.2. totalCounter 510 An integral value reporting the value of a counter. Counters are 511 unsigned and wrap back to zero after reaching the limit of the type. 512 For example, an unsigned64 with counter semantics will continue to 513 increment until reaching the value of 2**64 - 1. At this point, the 514 next increment will wrap its value to zero and continue counting from 515 zero. The semantics of a total counter is similar to the semantics 516 of counters used in SNMP, such as Counter32 defined in RFC 2578 517 [RFC2578]. The only difference between total counters and counters 518 used in SNMP is that the total counters have an initial value of 0. 519 A total counter counts independently of the export of its value. 521 3.2.3. deltaCounter 523 An integral value reporting the value of a counter. Counters are 524 unsigned and wrap back to zero after reaching the limit of the type. 525 For example, an unsigned64 with counter semantics will continue to 526 increment until reaching the value of 2**64 - 1. At this point, the 527 next increment will wrap its value to zero and continue counting from 528 zero. The semantics of a delta counter is similar to the semantics 529 of counters used in SNMP, such as Counter32 defined in RFC 2578 530 [RFC2578]. The only difference between delta counters and counters 531 used in SNMP is that the delta counters have an initial value of 0. 532 A delta counter is reset to 0 each time its value is exported. 534 3.2.4. identifier 536 An integral value that serves as an identifier. Specifically, 537 mathematical operations on two identifiers (aside from the equality 538 operation) are meaningless. For example, Autonomous System ID 1 * 539 Autonomous System ID 2 is meaningless. 541 3.2.5. flags 543 An integral value that actually represents a set of bit fields. 544 Logical operations are appropriate on such values, but not other 545 mathematical operations. Flags should always be of an unsigned type. 547 4. Information Element Identifiers 549 All Information Elements defined in Section 5 of this document or in 550 future extensions of the IPFIX information model have their 551 identifiers assigned by IANA. Their identifiers can be retrieved at 552 [IPFIX-IANA]. 554 The value of these identifiers is in the range of 1-32767. Within 555 this range, Information Element identifier values in the sub-range of 556 1-127 are compatible with field types used by NetFlow version 9 557 [RFC3954]. 559 +---------------------------------+---------------------------------+ 560 | Range of IANA-assigned | Description | 561 | Information Element identifiers | | 562 +---------------------------------+---------------------------------+ 563 | 0 | Reserved. | 564 | 1-127 | Information Element identifiers | 565 | | compatible with NetFlow version | 566 | | 9 field types [RFC3954]. | 567 | 128-32767 | Further Information Element | 568 | | identifiers. | 569 +---------------------------------+---------------------------------+ 571 Enterprise-specific Information Element identifiers have the same 572 range of 1-32767, but they are coupled with an additional enterprise 573 identifier. For enterprise-specific Information Elements, 574 Information Element identifier 0 is also reserved. 576 Enterprise-specific Information Element identifiers can be chosen by 577 an enterprise arbitrarily within the range of 1-32767. The same 578 identifier may be assigned by other enterprises for different 579 purposes. 581 Still, Collecting Processes can distinguish these Information 582 Elements because the Information Element identifier is coupled with 583 an enterprise identifier. 585 Enterprise identifiers MUST be registered as SMI network management 586 private enterprise code numbers with IANA. The registry can be found 587 at http://www.iana.org/assignments/enterprise-numbers. 589 The following list gives an overview of the Information Element 590 identifiers that are specified in Section 5 and are compatible with 591 field types used by NetFlow version 9 [RFC3954]. 593 +----+----------------------------+-------+-------------------------+ 594 | ID | Name | ID | Name | 595 +----+----------------------------+-------+-------------------------+ 596 | 1 | octetDeltaCount | 43 | RESERVED | 597 | 2 | packetDeltaCount | 44 | sourceIPv4Prefix | 598 | 3 | RESERVED | 45 | destinationIPv4Prefix | 599 | 4 | protocolIdentifier | 46 | mplsTopLabelType | 600 | 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address | 601 | 6 | tcpControlBits | 48-51 | RESERVED | 602 | 7 | sourceTransportPort | 52 | minimumTTL | 603 | 8 | sourceIPv4Address | 53 | maximumTTL | 604 | 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification | 605 | 10 | ingressInterface | 55 | postIpClassOfService | 606 | 11 | destinationTransportPort | 56 | sourceMacAddress | 607 | 12 | destinationIPv4Address | 57 |postDestinationMacAddress| 608 | 13 | destinationIPv4PrefixLength| 58 | vlanId | 609 | 14 | egressInterface | 59 | postVlanId | 610 | 15 | ipNextHopIPv4Address | 60 | ipVersion | 611 | 16 | bgpSourceAsNumber | 61 | flowDirection | 612 | 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address | 613 | 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address | 614 | 19 | postMCastPacketDeltaCount | 64 | ipv6ExtensionHeaders | 615 | 20 | postMCastOctetDeltaCount | 65-69 | RESERVED | 616 | 21 | flowEndSysUpTime | 70 | mplsTopLabelStackSection| 617 | 22 | flowStartSysUpTime | 71 | mplsLabelStackSection2 | 618 | 23 | postOctetDeltaCount | 72 | mplsLabelStackSection3 | 619 | 24 | postPacketDeltaCount | 73 | mplsLabelStackSection4 | 620 | 25 | minimumIpTotalLength | 74 | mplsLabelStackSection5 | 621 | 26 | maximumIpTotalLength | 75 | mplsLabelStackSection6 | 622 | 27 | sourceIPv6Address | 76 | mplsLabelStackSection7 | 623 | 28 | destinationIPv6Address | 77 | mplsLabelStackSection8 | 624 | 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackSection9 | 625 | 30 | destinationIPv6PrefixLength| 79 | mplsLabelStackSection10 | 626 | 31 | flowLabelIPv6 | 80 | destinationMacAddress | 627 | 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress | 628 | 33 | igmpType | 82-84 | RESERVED | 629 | 34 | RESERVED | 85 | octetTotalCount | 630 | 35 | RESERVED | 86 | packetTotalCount | 631 | 36 | flowActiveTimeout | 87 | RESERVED | 632 | 37 | flowIdleTimeout | 88 | fragmentOffset | 633 | 38 | RESERVED | 89 | RESERVED | 634 | 39 | RESERVED | 90 |mplsVpnRouteDistinguisher| 635 | 40 | exportedOctetTotalCount |91-127 | RESERVED | 636 | 41 | exportedMessageTotalCount | | | 637 | 42 |exportedFlowRecordTotalCount| | | 638 +----+----------------------------+-------+-------------------------+ 639 The following list gives an overview of the Information Element 640 identifiers that are specified in Section 5 and extends the list of 641 Information Element identifiers specified already in [RFC3954]. 643 +-----+---------------------------+-----+---------------------------+ 644 | ID | Name | ID | Name | 645 +-----+---------------------------+-----+---------------------------+ 646 | 128 | bgpNextAdjacentAsNumber | 169 | destinationIPv6Prefix | 647 | 129 | bgpPrevAdjacentAsNumber | 170 | sourceIPv6Prefix | 648 | 130 | exporterIPv4Address | 171 | postOctetTotalCount | 649 | 131 | exporterIPv6Address | 172 | postPacketTotalCount | 650 | 132 | droppedOctetDeltaCount | 173 | flowKeyIndicator | 651 | 133 | droppedPacketDeltaCount | 174 | postMCastPacketTotalCount | 652 | 134 | droppedOctetTotalCount | 175 | postMCastOctetTotalCount | 653 | 135 | droppedPacketTotalCount | 176 | icmpTypeIPv4 | 654 | 136 | flowEndReason | 177 | icmpCodeIPv4 | 655 | 137 | commonPropertiesId | 178 | icmpTypeIPv6 | 656 | 138 | observationPointId | 179 | icmpCodeIPv6 | 657 | 139 | icmpTypeCodeIPv6 | 180 | udpSourcePort | 658 | 140 | mplsTopLabelIPv6Address | 181 | udpDestinationPort | 659 | 141 | lineCardId | 182 | tcpSourcePort | 660 | 142 | portId | 183 | tcpDestinationPort | 661 | 143 | meteringProcessId | 184 | tcpSequenceNumber | 662 | 144 | exportingProcessId | 185 | tcpAcknowledgementNumber | 663 | 145 | templateId | 186 | tcpWindowSize | 664 | 146 | wlanChannelId | 187 | tcpUrgentPointer | 665 | 147 | wlanSSID | 188 | tcpHeaderLength | 666 | 148 | flowId | 189 | ipHeaderLength | 667 | 149 | observationDomainId | 190 | totalLengthIPv4 | 668 | 150 | flowStartSeconds | 191 | payloadLengthIPv6 | 669 | 151 | flowEndSeconds | 192 | ipTTL | 670 | 152 | flowStartMilliseconds | 193 | nextHeaderIPv6 | 671 | 153 | flowEndMilliseconds | 194 | mplsPayloadLength | 672 | 154 | flowStartMicroseconds | 195 | ipDiffServCodePoint | 673 | 155 | flowEndMicroseconds | 196 | ipPrecedence | 674 | 156 | flowStartNanoseconds | 197 | fragmentFlags | 675 | 157 | flowEndNanoseconds | 198 | octetDeltaSumOfSquares | 676 | 158 | flowStartDeltaMicroseconds| 199 | octetTotalSumOfSquares | 677 | 159 | flowEndDeltaMicroseconds | 200 | mplsTopLabelTTL | 678 | 160 | systemInitTimeMilliseconds| 201 | mplsLabelStackLength | 679 | 161 | flowDurationMilliseconds | 202 | mplsLabelStackDepth | 680 | 162 | flowDurationMicroseconds | 203 | mplsTopLabelExp | 681 | 163 | observedFlowTotalCount | 204 | ipPayloadLength | 682 | 164 | ignoredPacketTotalCount | 205 | udpMessageLength | 683 | 165 | ignoredOctetTotalCount | 206 | isMulticast | 684 | 166 | notSentFlowTotalCount | 207 | ipv4IHL | 685 | 167 | notSentPacketTotalCount | 208 | ipv4Options | 686 | 168 | notSentOctetTotalCount | 209 | tcpOptions | 687 +-----+---------------------------+-----+---------------------------+ 688 | ID | Name | ID | Name | 689 +-----+---------------------------+-----+---------------------------+ 690 | 210 | paddingOctets | 218 | tcpSynTotalCount | 691 | 211 | collectorIPv4Address | 219 | tcpFinTotalCount | 692 | 212 | collectorIPv6Address | 220 | tcpRstTotalCount | 693 | 213 | exportInterface | 221 | tcpPshTotalCount | 694 | 214 | exportProtocolVersion | 222 | tcpAckTotalCount | 695 | 215 | exportTransportProtocol | 223 | tcpUrgTotalCount | 696 | 216 | collectorTransportPort | 224 | ipTotalLength | 697 | 217 | exporterTransportPort | 237 | postMplsTopLabelExp | 698 | | | 238 | tcpWindowScale | 699 +-----+---------------------------+-----+---------------------------+ 701 5. Information Elements 703 This section describes the Information Element category for the IPFIX 704 information model at the time that RFC5102 [RFC5102] was published. 705 Since this category field is not part of the IANA process for 706 assigning new Information Element (even though it has been reused, 707 for example, in [RFC5103]), the newest Information Elements in IANA 708 [IPFIX-IANA] don't have this classification. The elements are 709 grouped into 12 groups according to their semantics and their 710 applicability: 712 1. Identifiers 713 2. Metering and Exporting Process Configuration 714 3. Metering and Exporting Process Statistics 715 4. IP Header Fields 716 5. Transport Header Fields 717 6. Sub-IP Header Fields 718 7. Derived Packet Properties 719 8. Min/Max Flow Properties 720 9. Flow Timestamps 721 10. Per-Flow Counters 722 11. Miscellaneous Flow Properties 723 12. Padding 725 The Information Elements that are derived from fields of packets or 726 from packet treatment, such as the Information Elements in groups 727 4-7, can typically serve as Flow Keys used for mapping packets to 728 Flows. 730 If they do not serve as Flow Keys, their value may change from packet 731 to packet within a single Flow. For Information Elements with values 732 that are derived from fields of packets or from packet treatment and 733 for which the value may change from packet to packet within a single 734 Flow, the IPFIX information model defines that their value is 735 determined by the first packet observed for the corresponding Flow, 736 unless the description of the Information Element explicitly 737 specifies a different semantics. This simple rule allows writing all 738 Information Elements related to header fields once when the first 739 packet of the Flow is observed. For further observed packets of the 740 same Flow, only Flow properties that depend on more than one packet, 741 such as the Information Elements in groups 8-11, need to be updated. 743 Information Elements with a name having the "post" prefix, for 744 example, "postIpClassOfService", do not report properties that were 745 actually observed at the Observation Point, but retrieved by other 746 means within the Observation Domain. These Information Elements can 747 be used if there are middlebox functions within the Observation 748 Domain changing Flow properties after packets passed the Observation 749 Point. 751 5.1. Identifiers 753 Information Elements grouped in the table below are identifying 754 components of the IPFIX architecture, of an IPFIX Device, or of the 755 IPFIX protocol. All of them have an integral abstract data type and 756 data type semantics "identifier" as described in Section 3.2.4. 758 Typically, some of them are used for limiting scopes of other 759 Information Elements. However, other Information Elements MAY be 760 used for limiting scopes. Note also that all Information Elements 761 listed below MAY be used for other purposes than limiting scopes. 763 +-----+---------------------------+-----+---------------------------+ 764 | ID | Name | ID | Name | 765 +-----+---------------------------+-----+---------------------------+ 766 | 141 | lineCardId | 148 | flowId | 767 | 142 | portId | 145 | templateId | 768 | 10 | ingressInterface | 149 | observationDomainId | 769 | 14 | egressInterface | 138 | observationPointId | 770 | 143 | meteringProcessId | 137 | commonPropertiesId | 771 | 144 | exportingProcessId | | | 772 +-----+---------------------------+-----+---------------------------+ 774 See [IPFIX-IANA] for the definitions of these Information Elements. 776 5.2. Metering and Exporting Process Configuration 778 Information Elements in this section describe the configuration of 779 the Metering Process or the Exporting Process. The set of these 780 Information Elements is listed in the table below. 782 +-----+--------------------------+-----+----------------------------+ 783 | ID | Name | ID | Name | 784 +-----+--------------------------+-----+----------------------------+ 785 | 130 | exporterIPv4Address | 213 | exportInterface | 786 | 131 | exporterIPv6Address | 214 | exportProtocolVersion | 787 | 217 | exporterTransportPort | 215 | exportTransportProtocol | 788 | 211 | collectorIPv4Address | 216 | collectorTransportPort | 789 | 212 | collectorIPv6Address | 173 | flowKeyIndicator | 790 +-----+--------------------------+-----+----------------------------+ 792 See [IPFIX-IANA] for the definitions of these Information Elements. 794 5.3. Metering and Exporting Process Statistics 796 Information Elements in this section describe statistics of the 797 Metering Process and/or the Exporting Process. The set of these 798 Information Elements is listed in the table below. 800 +-----+-----------------------------+-----+-------------------------+ 801 | ID | Name | ID | Name | 802 +-----+-----------------------------+-----+-------------------------+ 803 | 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount | 804 | 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount | 805 | 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount | 806 | 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount | 807 | 164 | ignoredPacketTotalCount | | | 808 +-----+-----------------------------+-----+-------------------------+ 810 See [IPFIX-IANA] for the definitions of these Information Elements. 812 5.4. IP Header Fields 814 Information Elements in this section indicate values of IP header 815 fields or are derived from IP header field values in combination with 816 further information. 818 +-----+----------------------------+-----+--------------------------+ 819 | ID | Name | ID | Name | 820 +-----+----------------------------+-----+--------------------------+ 821 | 60 | ipVersion | 193 | nextHeaderIPv6 | 822 | 8 | sourceIPv4Address | 195 | ipDiffServCodePoint | 823 | 27 | sourceIPv6Address | 196 | ipPrecedence | 824 | 9 | sourceIPv4PrefixLength | 5 | ipClassOfService | 825 | 29 | sourceIPv6PrefixLength | 55 | postIpClassOfService | 826 | 44 | sourceIPv4Prefix | 31 | flowLabelIPv6 | 827 | 170 | sourceIPv6Prefix | 206 | isMulticast | 828 | 12 | destinationIPv4Address | 54 | fragmentIdentification | 829 | 28 | destinationIPv6Address | 88 | fragmentOffset | 830 | 13 | destinationIPv4PrefixLength| 197 | fragmentFlags | 831 | 30 | destinationIPv6PrefixLength| 189 | ipHeaderLength | 832 | 45 | destinationIPv4Prefix | 207 | ipv4IHL | 833 | 169 | destinationIPv6Prefix | 190 | totalLengthIPv4 | 834 | 192 | ipTTL | 224 | ipTotalLength | 835 | 4 | protocolIdentifier | 191 | payloadLengthIPv6 | 836 +-----+----------------------------+-----+--------------------------+ 838 See [IPFIX-IANA] for the definitions of these Information Elements. 840 5.5. Transport Header Fields 842 The set of Information Elements related to transport header fields 843 and length includes the Information Elements listed in the table 844 below. 846 +-----+---------------------------+-----+---------------------------+ 847 | ID | Name | ID | Name | 848 +-----+---------------------------+-----+---------------------------+ 849 | 7 | sourceTransportPort | 238 | tcpWindowScale | 850 | 11 | destinationTransportPort | 187 | tcpUrgentPointer | 851 | 180 | udpSourcePort | 188 | tcpHeaderLength | 852 | 181 | udpDestinationPort | 32 | icmpTypeCodeIPv4 | 853 | 205 | udpMessageLength | 176 | icmpTypeIPv4 | 854 | 182 | tcpSourcePort | 177 | icmpCodeIPv4 | 855 | 183 | tcpDestinationPort | 139 | icmpTypeCodeIPv6 | 856 | 184 | tcpSequenceNumber | 178 | icmpTypeIPv6 | 857 | 185 | tcpAcknowledgementNumber | 179 | icmpCodeIPv6 | 858 | 186 | tcpWindowSize | 33 | igmpType | 859 +-----+---------------------------+-----+---------------------------+ 861 See [IPFIX-IANA] for the definitions of these Information Elements. 863 5.6. Sub-IP Header Fields 865 The set of Information Elements related to Sub-IP header fields 866 includes the Information Elements listed in the table below. 868 +-----+---------------------------+-----+---------------------------+ 869 | ID | Name | ID | Name | 870 +-----+---------------------------+-----+---------------------------+ 871 | 56 | sourceMacAddress | 201 | mplsLabelStackLength | 872 | 81 | postSourceMacAddress | 194 | mplsPayloadLength | 873 | 58 | vlanId | 70 | mplsTopLabelStackSection | 874 | 59 | postVlanId | 71 | mplsLabelStackSection2 | 875 | 80 | destinationMacAddress | 72 | mplsLabelStackSection3 | 876 | 57 | postDestinationMacAddress | 73 | mplsLabelStackSection4 | 877 | 146 | wlanChannelId | 74 | mplsLabelStackSection5 | 878 | 147 | wlanSSID | 75 | mplsLabelStackSection6 | 879 | 200 | mplsTopLabelTTL | 76 | mplsLabelStackSection7 | 880 | 203 | mplsTopLabelExp | 77 | mplsLabelStackSection8 | 881 | 237 | postMplsTopLabelExp | 78 | mplsLabelStackSection9 | 882 | 202 | mplsLabelStackDepth | 79 | mplsLabelStackSection10 | 883 +-----+---------------------------+-----+---------------------------+ 885 See [IPFIX-IANA] for the definitions of these Information Elements. 887 5.7. Derived Packet Properties 889 The set of Information Elements derived from packet properties (for 890 example, values of header fields) includes the Information Elements 891 listed in the table below. 893 +-----+---------------------------+-----+---------------------------+ 894 | ID | Name | ID | Name | 895 +-----+---------------------------+-----+---------------------------+ 896 | 204 | ipPayloadLength | 18 | bgpNextHopIPv4Address | 897 | 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address | 898 | 62 | ipNextHopIPv6Address | 46 | mplsTopLabelType | 899 | 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address | 900 | 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address | 901 | 128 | bgpNextAdjacentAsNumber | 90 | mplsVpnRouteDistinguisher | 902 | 129 | bgpPrevAdjacentAsNumber | | | 903 +-----+---------------------------+-----+---------------------------+ 905 See [IPFIX-IANA] for the definitions of these Information Elements. 907 5.9. Flow Timestamps 908 Information Elements in this section are timestamps of events. 910 Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds, 911 flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds, 912 flowStartNanoseconds, flowEndNanoseconds, and 913 systemInitTimeMilliseconds are absolute and have a well-defined fixed 914 time base, such as, for example, the number of seconds since 0000 UTC 915 Jan 1st 1970. 917 Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 918 are relative timestamps only valid within the scope of a single 919 IPFIX Message. They contain the negative time offsets relative to 920 the export time specified in the IPFIX Message Header. The maximum 921 time offset that can be encoded by these delta counters is 1 hour, 11 922 minutes, and 34.967295 seconds. 924 Timestamps flowStartSysUpTime and flowEndSysUpTime are relative 925 timestamps indicating the time relative to the last 926 (re-)initialization of the IPFIX Device. For reporting the time 927 of the last (re-)initialization, systemInitTimeMilliseconds can 928 be reported, for example, in Data Records defined by Option 929 Templates. 931 +-----+---------------------------+-----+---------------------------+ 932 | ID | Name | ID | Name | 933 +-----+---------------------------+-----+---------------------------+ 934 | 150 | flowStartSeconds | 156 | flowStartNanoseconds | 935 | 151 | flowEndSeconds | 157 | flowEndNanoseconds | 936 | 152 | flowStartMilliseconds | 158 | flowStartDeltaMicroseconds| 937 | 153 | flowEndMilliseconds | 159 | flowEndDeltaMicroseconds | 938 | 154 | flowStartMicroseconds | 160 | systemInitTimeMilliseconds| 939 | 155 | flowEndMicroseconds | 22 | flowStartSysUpTime | 940 | | | 21 | flowEndSysUpTime | 941 +-----+---------------------------+-----+---------------------------+ 943 See [IPFIX-IANA] for the definitions of these Information Elements. 945 5.10. Per-Flow Counters 947 Information Elements in this section are counters all having integer 948 values. Their values may change for every report they are used in. 949 They cannot serve as part of a Flow Key used for mapping packets to 950 Flows. However, potentially they can be used for selecting exported 951 Flows, for example, by only exporting Flows with more than a 952 threshold number of observed octets. 954 There are running counters and delta counters. Delta counters are 955 reset to zero each time their values are exported. Running counters 956 continue counting independently of the Exporting Process. 958 There are per-Flow counters and counters related to the Metering 959 Process and/or the Exporting Process. Per-Flow counters are Flow 960 properties that potentially change each time a packet belonging to 961 the Flow is observed. The set of per-Flow counters includes the 962 Information Elements listed in the table below. Counters related to 963 the Metering Process and/or the Exporting Process are described in 964 Section 5.3. 966 +-----+---------------------------+-----+---------------------------+ 967 | ID | Name | ID | Name | 968 +-----+---------------------------+-----+---------------------------+ 969 | 1 | octetDeltaCount | 134 | droppedOctetTotalCount | 970 | 23 | postOctetDeltaCount | 135 | droppedPacketTotalCount | 971 | 198 | octetDeltaSumOfSquares | 19 | postMCastPacketDeltaCount | 972 | 85 | octetTotalCount | 20 | postMCastOctetDeltaCount | 973 | 171 | postOctetTotalCount | 174 | postMCastPacketTotalCount | 974 | 199 | octetTotalSumOfSquares | 175 | postMCastOctetTotalCount | 975 | 2 | packetDeltaCount | 218 | tcpSynTotalCount | 976 | 24 | postPacketDeltaCount | 219 | tcpFinTotalCount | 977 | 86 | packetTotalCount | 220 | tcpRstTotalCount | 978 | 172 | postPacketTotalCount | 221 | tcpPshTotalCount | 979 | 132 | droppedOctetDeltaCount | 222 | tcpAckTotalCount | 980 | 133 | droppedPacketDeltaCount | 223 | tcpUrgTotalCount | 981 +-----+---------------------------+-----+---------------------------+ 983 See [IPFIX-IANA] for the definitions of these Information Elements. 985 5.11. Miscellaneous Flow Properties 987 Information Elements in this section describe properties of Flows 988 that are related to Flow start, Flow duration, and Flow termination, 989 but they are not timestamps as the Information Elements in Section 990 5.9 are. 992 +-----+---------------------------+-----+---------------------------+ 993 | ID | Name | ID | Name | 994 +-----+---------------------------+-----+---------------------------+ 995 | 36 | flowActiveTimeout | 161 | flowDurationMilliseconds | 996 | 37 | flowIdleTimeout | 162 | flowDurationMicroseconds | 997 | 136 | flowEndReason | 61 | flowDirection | 998 +-----+---------------------------+-----+---------------------------+ 1000 See [IPFIX-IANA] for the definitions of these Information Elements. 1002 5.12. Padding 1004 This section contains a single Information Element that can be used 1005 for padding of Flow Records. 1007 IPFIX implementations may wish to align Information Elements within 1008 Data Records or to align entire Data Records to 4-octet or 8-octet 1009 boundaries. This can be achieved by including one or more 1010 paddingOctets Information Elements in a Data Record. 1012 +-----+---------------------------+-----+---------------------------+ 1013 | ID | Name | ID | Name | 1014 +-----+---------------------------+-----+---------------------------+ 1015 | 210 | paddingOctets | | | 1016 +-----+---------------------------+-----+---------------------------+ 1018 See [IPFIX-IANA] for the definitions of these Information Elements. 1020 6. Extending the Information Model 1022 A key requirement for IPFIX is to allow for extension of the 1023 Information Model maintained by IANA. The process for extending the 1024 Information Model is defined in [IPFIX-IE-DOCTORS], which also 1025 provides guidelines for authors and reviewers of new Information 1026 Element definitions. 1028 For new Information Models, the type space defined in Section 3 can 1029 be used. If required, new abstract data types can be added to the 1030 subregistry defined in [RFC5610]. New abstract data types MUST be 1031 defined in IETF Standards Track documents. 1033 Enterprises may wish to define Information Elements without 1034 registering them with IANA. IPFIX explicitly supports 1035 enterprise-specific Information Elements. Enterprise-specific 1036 Information Elements are described in Sections 2.1 and 4; guidelines 1037 for using them appear in [IPFIX-IE-DOCTORS]. 1039 7. IANA Considerations 1041 7.1. IPFIX Information Elements 1043 This document refers to the Information Elements, for which the Internet 1044 Assigned Numbers Authority (IANA) has created a registry for IPFIX 1045 Information Element identifiers [IPFIX-IANA]. 1047 New assignments for IPFIX Information Elements will be administered 1048 by IANA through Expert Review [RFC5226], i.e., review by one of a 1049 group of experts designated by an IETF Area Director. The group of 1050 experts MUST check the requested Information Element for completeness 1051 and accuracy of the description and for correct naming according to 1052 the naming conventions in Section 2.3. Requests for Information 1053 Elements that duplicate the functionality of existing Information 1054 Elements SHOULD be declined. The smallest available identifier 1055 SHOULD be assigned to a new Information Element. 1057 The specification of new IPFIX Information Elements MUST use the 1058 template specified in Section 2.1 and MUST be published using a 1059 well-established and persistent publication medium. The experts 1060 will initially be drawn from the Working Group Chairs and document 1061 editors of the IPFIX and PSAMP Working Groups. 1063 7.2. MPLS Label Type Identifier 1065 Information Element #46, named mplsTopLabelType, carries MPLS label 1066 types. Values for 5 different types have initially been defined. 1067 For ensuring extensibility of this information, IANA has created 1068 a new registry for MPLS label types and filled it with the 1069 initial list from the description Information Element #46, 1070 mplsTopLabelType. 1072 New assignments for MPLS label types will be administered by IANA 1073 through Expert Review [RFC5226], i.e., review by one of a group of 1074 experts designated by an IETF Area Director. The group of experts 1075 must double check the label type definitions with already defined 1076 label types for completeness, accuracy, and redundancy. The 1077 specification of new MPLS label types MUST be published using a 1078 well-established and persistent publication medium. 1080 7.3. XML Namespace and Schema 1082 [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element 1083 definitions. All Information Elements specified in [IPFIX-IANA] are 1084 defined by this schema. This schema may also be used for specifying 1085 further Information Elements in future extensions of the IPFIX 1086 information model in a machine-readable way. 1088 [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an 1089 XML schema for IPFIX Information Elements conforming to a registry 1090 mechanism described in [RFC3688]. Two URI assignments have been made. 1092 1. Registration for the IPFIX information model namespace 1093 * URI: urn:ietf:params:xml:ns:ipfix-info 1094 * Registrant Contact: IETF IPFIX Working Group , 1095 as designated by the IESG . 1097 * XML: None. Namespace URIs do not represent an XML. 1099 2. Registration for the IPFIX information model schema 1100 * URI: urn:ietf:params:xml:schema:ipfix-info 1101 * Registrant Contact: IETF IPFIX Working Group , 1102 as designated by the IESG . 1104 Using a machine-readable syntax for the information model enables the 1105 creation of IPFIX-aware tools that can automatically adapt to 1106 extensions to the information model, by simply reading updated 1107 information model specifications. 1109 The wide availability of XML-aware tools and libraries for client 1110 devices is a primary consideration for this choice. In particular, 1111 libraries for parsing XML documents are readily available. Also, 1112 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 1113 transforming a source XML document into other documents. This 1114 document was authored in XML and transformed according to [RFC2629]. 1116 It should be noted that the use of XML in Exporters, Collectors, or 1117 other tools is not mandatory for the deployment of IPFIX. In 1118 particular, Exporting Processes do not produce or consume XML as part 1119 of their operation. It is expected that IPFIX Collectors MAY take 1120 advantage of the machine readability of the information model vs. 1121 hard coding their behavior or inventing proprietary means for 1122 accommodating extensions. 1124 8. Security Considerations 1126 The IPFIX information model itself does not directly introduce security 1127 issues. Rather, it defines a set of attributes that may for privacy or 1128 business issues be considered sensitive information. 1130 For example, exporting values of header fields may make attacks possible 1131 for the receiver of this information, which would otherwise only be 1132 possible for direct observers of the reported Flows along the data path. 1134 The underlying protocol used to exchange the information described here 1135 must therefore apply appropriate procedures to guarantee the integrity 1136 and confidentiality of the exported information. Such protocols are 1137 defined in separate documents, specifically the IPFIX protocol document 1138 [RFC5101bis]. 1140 This document does not specify any Information Element carrying keying 1141 material. If future extensions will do so, then appropriate precautions 1142 need to be taken for properly protecting such sensitive information. 1144 9. Acknowledgements 1146 The editors would like to thanks the authors of the RFC5102 [RFC5102], 1147 as this document is based upon and develop this original RFC: Juergen 1148 Quittek, Stewart Bryant, Paul Aitken, and Jeff Meyer. 1150 10. References 1152 10.1. Normative References 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", BCP 14, RFC 2119, March 1997. 1157 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and W. 1158 Kasch, "Network Time Protocol Version 4: Protocol and 1159 Algorithms Specification", RFC 5905, June 2010 1161 [RFC5101bis] Claise, B., and B. Trammell, Editors, "Specification of 1162 the IP Flow Information eXport (IPFIX) Protocol for the 1163 Exchange of IP Traffic Flow Information", draft-ietf- 1164 ipfix-protocol-rfc5101bis-00, Work in Progress, November 1165 2011. 1167 [IPFIX-IE-DOCTORS] Trammell, T., and B. Claise, "Guidelines for 1168 Authors and Reviewers of IPFIX Information Elements", 1169 draft-ietf-ipfix-ie-doctors-00, Work in Progress, November 1170 2011. 1172 10.2. Informative References 1174 [IEEE.754.1985] 1175 Institute of Electrical and Electronics Engineers, 1176 "Standard for Binary Floating-Point Arithmetic", IEEE 1177 Standard 754, August 1985. 1179 [ISO.10646-1.1993] 1180 International Organization for Standardization, 1181 "Information Technology - Universal Multiple-octet coded 1182 Character Set (UCS) - Part 1: Architecture and Basic 1183 Multilingual Plane", ISO Standard 10646-1, May 1993. 1185 [ISO.646.1991] 1186 International Organization for Standardization, 1187 "Information technology - ISO 7-bit coded character set 1188 for information interchange", ISO Standard 646, 1991. 1190 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1191 "Structure of Management Information Version 2 (SMIv2)", 1192 STD 58, RFC 2578, April 1999. 1194 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1195 June 1999. 1197 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1198 Issues", RFC 3234, February 2002. 1200 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1201 Information Models and Data Models", RFC 3444, January 1202 2003. 1204 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1205 January 2004. 1207 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1208 "Requirements for IP Flow Information Export (IPFIX)", RFC 1209 3917, October 2004. 1211 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1212 Version 9", RFC 3954, October 2004. 1214 [RFC5102] Trammell, B., and E. Boschi, "Bidirectional Flow Export 1215 Using IP Flow Information Export (IPFIX)", RFC 5103, 1216 January 2008. 1218 [RFC5103] Quittek, J., Bryant, S. Claise, B., Aitken, P., and J. 1219 Meyer, "Information Model for IP Flow Information Export", 1220 RFC 5102, January 2008. 1222 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow 1223 Information Export (IPFIX) Implementation Guidelines", 1224 RFC5153, April 2008. 1226 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1227 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1228 May 2008. 1230 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1231 "Architecture for IP Flow Information Export", RFC5470, 1232 March 2009. 1234 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP 1235 Flow Information Export (IPFIX) Testing", RFC5471, March 1236 2009. 1238 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1239 Flow Information Export (IPFIX) Applicability", RFC5472, 1240 March 2009. 1242 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy 1243 in IP Flow Information Export (IPFIX) and Packet Sampling 1244 (PSAMP) Reports", RFC5473, March 2009. 1246 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1247 "Exporting Type Information for IP Flow Information Export 1248 (IPFIX) Information Elements", July 2009. 1250 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 1251 "Export of Structured Data in IP Flow Information Export 1252 (IPFIX)", RFC6313, July 2011. 1254 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP 1255 Flow Information Export (IPFIX) Mediation: Framework", 1256 RFC6183, April 2011. 1258 [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken, "Configuration 1259 Data Model for IPFIX and PSAMP", draft-ietf-ipfix- 1260 configuration-model-10, Work in Progress, July 2011. 1262 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 1263 "Specification of the Protocol for IPFIX Mediations", 1264 draft-ietf-ipfix-mediation-protocol-00, Work in Progress, 1265 December 2011. 1267 [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 1268 "Definitions of Managed Objects for IP Flow Information 1269 Export", draft-ietf-ipfix-rfc5815bis-01.txt, Work in 1270 Progress, January 2012. 1272 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 1274 [IPFIX-XML-SCHEMA] http://www.iana.org/assignments/xml- 1275 registry/schema/ipfix.xsd 1277 Authors' Addresses 1279 Benoit Claise 1280 Cisco Systems, Inc. 1281 De Kleetlaan 6a b1 1282 Diegem 1831 1283 Belgium 1285 Phone: +32 2 704 5622 1286 EMail: bclaise@cisco.com 1288 Brian Trammell 1289 Swiss Federal Institute of Technology Zurich 1290 Gloriastrasse 35 1291 8092 Zurich 1292 Switzerland 1294 Phone: +41 44 632 70 13 1295 EMail: trammell@tik.ee.ethz.ch