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