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