idnits 2.17.1 draft-ietf-ipfix-info-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 171: '... by an extension MUST have the followi...' RFC 2119 keyword, line 202: '... by an extension MAY have the followin...' RFC 2119 keyword, line 205: '...ange, a vendorId MUST be provided. Thi...' RFC 2119 keyword, line 914: '...ent. Each new information item MUST be...' RFC 2119 keyword, line 1075: '...xpected that IPFIX collectors MAY take...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2004) is 7347 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) -- Looks like a reference, but probably isn't: 'IPFIX-PROTO' on line 135 == Unused Reference: '1' is defined on line 960, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 967, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 972, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 977, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 982, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 986, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 990, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 994, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 998, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1018, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-02 == Outdated reference: A later version (-16) exists of draft-ietf-ipfix-reqs-15 == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. '11') (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calato 3 Internet-Draft Riverstone Networks Inc 4 Expires: August 16, 2004 J. Meyer 5 PayPal 6 J. Quittek 7 NEC Europe Ltd. 8 February 16, 2004 10 Information Model for IP Flow Information Export 11 draft-ietf-ipfix-info-03 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 16, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This memo defines and information model for the IP Flow Information 42 eXport (IPFIX) protocol. It is used by the IPFIX protocol for 43 encoding measured traffic information and information related to the 44 traffic observation point, the traffic metering process and the 45 exporting process. Although developed for the IPFIX protcol, the 46 model is defined in an open way that easily allows using it in other 47 protocols, interfaces, and applications. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Properties of IPFIX Protocol Fields . . . . . . . . . . . . 5 53 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1 octet . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.5 float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.6 boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.7 octetArray . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.8 string . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . . . . 8 63 3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . . 8 64 3.11 ipv4Address . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.12 ipv6Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4. Flow Attributes . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1 octetCount . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2 packetCount . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3 flowCount . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4 protocolIdentifier . . . . . . . . . . . . . . . . . . . . . 9 71 4.5 classOfService . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.7 sourcePort . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.8 sourceAddressV4 . . . . . . . . . . . . . . . . . . . . . . 11 75 4.9 sourceMask . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.10 ingressInterface . . . . . . . . . . . . . . . . . . . . . . 12 77 4.11 destinationPort . . . . . . . . . . . . . . . . . . . . . . 12 78 4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . . 13 79 4.13 destinationMask . . . . . . . . . . . . . . . . . . . . . . 13 80 4.14 egressInterface . . . . . . . . . . . . . . . . . . . . . . 13 81 4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . . 13 82 4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.17 destinationAsNumber . . . . . . . . . . . . . . . . . . . . 14 84 4.18 bgpNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . 14 85 4.19 mcPacketsSent . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.20 mcOctetsSent . . . . . . . . . . . . . . . . . . . . . . . . 15 87 4.21 flowEndTime . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.22 flowCreationTime . . . . . . . . . . . . . . . . . . . . . . 15 89 4.23 sourceAddressV6 . . . . . . . . . . . . . . . . . . . . . . 15 90 4.24 destinationAddressV6 . . . . . . . . . . . . . . . . . . . . 15 91 4.25 anotherSourceMask . . . . . . . . . . . . . . . . . . . . . 16 92 4.26 destinationMask . . . . . . . . . . . . . . . . . . . . . . 16 93 4.27 flowLabel . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.28 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.29 igmpType . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 4.30 samplingInterval . . . . . . . . . . . . . . . . . . . . . . 17 97 4.31 samplingAlgorithm . . . . . . . . . . . . . . . . . . . . . 17 98 4.32 flowReportingInterval . . . . . . . . . . . . . . . . . . . 18 99 4.33 flowIdleTimeout . . . . . . . . . . . . . . . . . . . . . . 18 100 4.34 exportedOctetCount . . . . . . . . . . . . . . . . . . . . . 18 101 4.35 exportedPacketCount . . . . . . . . . . . . . . . . . . . . 18 102 4.36 exportedFlowCount . . . . . . . . . . . . . . . . . . . . . 19 103 4.37 ipVersion . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 4.38 ipNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . . 19 105 4.39 bgpNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . 20 106 4.40 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 20 107 4.41 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 20 108 4.42 exporterAddressV4 . . . . . . . . . . . . . . . . . . . . . 20 109 4.43 exporterAddressV6 . . . . . . . . . . . . . . . . . . . . . 21 110 4.44 droppedOctetCount . . . . . . . . . . . . . . . . . . . . . 21 111 4.45 droppedPacketCount . . . . . . . . . . . . . . . . . . . . . 21 112 4.46 flowEndReason . . . . . . . . . . . . . . . . . . . . . . . 21 113 5. Extending the Information Model . . . . . . . . . . . . . . 23 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 115 7. Security Considerations . . . . . . . . . . . . . . . . . . 25 116 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 117 Normative Reference . . . . . . . . . . . . . . . . . . . . 27 118 Informative Reference . . . . . . . . . . . . . . . . . . . 28 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 120 A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 30 121 B. Formal Specification of Abstract Data Types . . . . . . . . 43 122 Intellectual Property and Copyright Statements . . . . . . . 53 124 1. Introduction 126 The IP Flow Information eXport (IPFIX) protocol serves for 127 transmitting information related to measured IP traffic over the 128 Internet. The protocol specification in [IPFIX-PROTO] defines how 129 information elements are transmitted. For information elements, it 130 specifies the encoding of a set of basic data types. However, the 131 list of fields that can be transmitted by the protocol, such as flow 132 attributes (source IP address, number of packets, etc.) and 133 information about the metering and exporting process (packet 134 observation point, smapling rate, flow timeout interval, etc.), is 135 not specified in [IPFIX-PROTO]. 137 This document complements the IPFIX protocol specification by 138 providing the IPFIX information model. The main part of this 139 document is Section 5 defines the (extensible) list of fields to be 140 transmitted by the IPFIX protcol. Section 2 defines a template for 141 specifying IPFIX fields that is used in Section 4. Section 3 defines 142 the set of abstract data types that are available for IPFIX fields. 143 Section 5 discusses extensibility of the IPFIX information model. 145 The main bodies of Sections 2, 3 and 4 were generated from XML 146 documents. The XML-based specification of template, abstract data 147 types and IPFIX fields can be used for automatically checking 148 syntactical correctness of the specification of IPFIX fields. 149 Further it can be used for generating IPFIX protocol implementation 150 code that deals with processing IPFIX fields. Also code for 151 applications that further process traffic information transmitted via 152 the IPFIX protocol can be generated with the XML specification of 153 IPFIX fields. 155 For that reason, the XML document that served as source for Section 4 156 and the XML schema that served as source for Sections 2 and 3 are 157 attached to this document in Appendices A and B. 159 Note that although partially generated from the attached XML 160 documents, the main body of this document is normative while the 161 appendices are informational. 163 2. Properties of IPFIX Protocol Fields 165 Fields of the IPFIX protocol carrying information about traffic 166 measurement are modeled as elements of the IPFIX information model 167 and specified in Section 4. For defining the fields, a template is 168 used that is specified below. 170 All fields specified for the IPFIX protocol either in this document 171 or by an extension MUST have the following properties defined: 173 name - A unique and meaningful name for the field. The preferred 174 spelling for the name is to use mixed case if the name is 175 compound, with an initial lower case letter. (E.g. 176 "sourceIpAddress"). 178 fieldType - A numeric identifier administered by IANA. This is used 179 for compact identification of an information item when encoding 180 templates in the protocol. 182 description - The semantics of this information element. Describes 183 how this field is derived from the flow or other information 184 available to the observer. 186 dataType - One of the types listed in the "Type Space" section. The 187 type space for attributes is constrained to facilitate 188 implementation. The existing type space does however encompass 189 most basic types used in modern programming languages, as well as 190 some derived types (such as IPAddress) which are common to this 191 domain and useful to distinguish. 193 dataTypeSemantics - The integral types may be qualified by additional 194 semantic details. Qualifying the fields as 'quantity', 'counter', 195 'identifier' or 'flags'. 197 applicability - to be done ... 199 status - to be done ... 201 All fields specified for the IPFIX protocol either in this document 202 or by an extension MAY have the following properties defined: 204 vendorId - When extension is done outside of the scope of the IANA 205 IPFIX fieldId range, a vendorId MUST be provided. This identifier 206 is based on IANA assigned enterprise identifiers. 208 usage - to be done ... 210 units - If the field is a measure of some kind, the units identify 211 what the measure is. 213 enumeratedRange - Some items may have a specific set of numeric 214 identifiers associated with a set of discrete values this element 215 may take. The meaning of each discrete value and a human readable 216 name should be assigned. 218 range - Some elements may only be able to take on a restricted set of 219 values which can be expressed as a range (e.g. 0 through 511 220 inclusive). If this is the case, the valid inclusive range should 221 be specified. 223 reference - Identifies additional specifications which more precisely 224 define this item or provide additional context for its use. 226 3. Type Space 228 The following subsections describe the abstract data types that can 229 be used for the specification of IPFIX fields in Section 4. 231 3.1 octet 233 The type "unsignedByte" represents a non-negative integer value in 234 the range of 0 to 255. 236 3.2 unsigned16 238 The type "unsigned16" represents a non-negative integer value in the 239 range of 0 to 65535. 241 3.3 unsigned32 243 The type "unsigned32" represents a non-negative integer value in the 244 range of 0 to 4294967295. 246 3.4 unsigned64 248 The type "unsigned64" represents a non-negative integer value in the 249 range of 0 to 18446744073709551615. 251 3.5 float32 253 The type "float32" corresponds to an IEEE single-precision 32-bit 254 floating point type. 256 3.6 boolean 258 The type "boolean" represents a binary value. 260 3.7 octetArray 262 The type "octetArray" represents a finite length string of octets. 264 3.8 string 266 The type "string" represents a finite length string of valid 267 characters from the Unicode character encoding set. Unicode allows 268 for ASCII and many other international character sets to be used. It 269 is expected that strings will be encoded in UTF-8 format, which is 270 identical in encoding for USASCII characters, but also accomodates 271 other Unicode multibyte characters. 273 3.9 dateTimeSeconds 275 The type "dateTimeSeconds" represents a time value having a precision 276 of seconds and normalized to the GMT timezone. Such types are in 277 common use on many operating systems and have the advantage that they 278 can be stored in 32-bit integers. 280 3.10 dataTimeMicroSeconds 282 The type "dateTimeSeconds" represents a time value having a precision 283 of microseconds and normalized to the GMT timezone. 285 3.11 ipv4Address 287 The type "ipv4Addr" represents a value of an IPv4 address. These 288 addresses are typically stored as 32-bit integers. 290 3.12 ipv6Address 292 The type "ipv6Addr" represents a value of an IPv6 address. 294 4. Flow Attributes 296 4.1 octetCount 298 Description: The number of observed octets. 300 Abstract Data Type: unsigned64 302 Field Id: 1 304 Units: octets 306 4.2 packetCount 308 Description: The number of observed packets. 310 Abstract Data Type: unsigned64 312 Field Id: 2 314 Units: packets 316 4.3 flowCount 318 Description: The number of (aggregated) flows. 320 Abstract Data Type: unsigned64 322 Field Id: 3 324 Units: flows 326 4.4 protocolIdentifier 328 Description: 330 The protocol number that identifies the IP packet payload. 331 Protocol numbers are defined in the IANA Protocol Numbers 332 registry. 334 In Internet Protocol version 4 (IPv4) this is carried in the 335 "Protocol" field. In Internet Protocol version 6 (IPv6) this is 336 carried in the "Next Header" field. 338 Abstract Data Type: octet 340 Data Type Semantics: identifier 341 Field Id: 4 343 Reference: 345 See RFC 791 for the specification of the IPv4 protocol field. See 346 RFC 1883 for the specification of the IPv6 protocol field. See 347 list of protocol numbers assigned by IANA at http://www.iana.org/ 348 assignments/protocol-numbers. 350 4.5 classOfService 352 Description: 354 The class of service. 356 The definition of classOfService is dependent on the protocol 357 being observed. Those considered here are: 359 * For IPv4 packets the class of service is given by the value of 360 the type of service field in the IPv4 packet header. 362 * For IPv6 packets the class of service is given by the value of 363 the traffic class field in the IPv6 packet header. 365 * For MPLS the class of service is given by the value of the 366 experimental use (Exp) field in label stack entries. The Exp 367 field has a length of 3 bits. These are mapped to the three 368 least valued bits of the classOfService octet. All other bits 369 of the octet are set to zero. 371 * For VLAN the class of service is given by the value of the type 372 of the user_priority field as defined in IEEE802.1q[802.1q] and 373 IEEE 802.1p[802.1p]. 375 EDITORS' NOTE: THIS NEEDS FURTHER WORK 377 Abstract Data Type: octet 379 Data Type Semantics: identifier 381 Field Id: 5 383 Reference: 385 See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 386 for the definition of the IPv6 traffic class field. See RFC 3032 387 for the definition of the Exp field in label stack entries. See 388 IEEE802.1q and IEEE 802.1p for the definition of the VLAN 389 user_priority field. 391 4.6 tcpControlBits 393 Description: 395 The TCP control bits seen for this flow. Note that a 0 value for 396 each bit only indicates that the flag was not detected (i.e. it 397 may have occurred but was not detected by the reporting CCE). 398 EDITORS' NOTE: THIS NEEDS FURTHER WORK. The bit mapping needs to 399 be specified. 401 Abstract Data Type: octet 403 Data Type Semantics: flags 405 Field Id: 6 407 Reference: See RFC 793 for a definiton of the TCP control bits in the 408 TCP header. 410 4.7 sourcePort 412 Description: A source port number in the UDP or TCP header, 413 respectively. 415 Abstract Data Type: unsigned16 417 Data Type Semantics: identifier 419 Field Id: 7 421 Reference: 423 See RFC 768 for the definiton of the UDP source port field. See 424 RFC 793 for the definiton of the TCP source port field. Additional 425 information on defined UDP and TCP port numbers can be found at 426 http://www.iana.org/assignments/port-numbers. 428 4.8 sourceAddressV4 430 Description: The IPv4 source address in the IPv4 packet header. 432 Abstract Data Type: ipv4Address 433 Field Id: 8 435 Reference: See RFC 791 for the definition of the IPv4 source address 436 field. 438 4.9 sourceMask 440 Description: The number of contiguous bits that are relevant in the 441 source address field of the IP packet header (i.e. the subnet mask 442 in slash notation). 444 Abstract Data Type: octet 446 Field Id: 9 448 Units: bits 450 4.10 ingressInterface 452 Description: The index of the IP interface (ifIndex) where packets of 453 a flow are being received. 455 Abstract Data Type: unsigned32 457 Data Type Semantics: identifier 459 Field Id: 10 461 Reference: See RFC 2863 for the definition of the ifIndex object. 463 4.11 destinationPort 465 Description: A destination port number in the UDP or TCP header, 466 respectively. 468 Abstract Data Type: unsigned16 470 Data Type Semantics: identifier 472 Field Id: 11 474 Reference: 476 See RFC 768 for the definiton of the UDP destination port field. 477 See RFC 793 for the definiton of the TCP destination port field. 478 Additional information on defined UDP and TCP port numbers can be 479 found at http://www.iana.org/assignments/port-numbers. 481 4.12 destinationAddressV4 483 Description: The IPv4 destination address in the IPv4 packet header. 485 Abstract Data Type: ipv4Address 487 Field Id: 12 489 Reference: See RFC 791 for the definition of the IPv4 destination 490 address field. 492 4.13 destinationMask 494 Description: 496 The number of contiguous bits that are relevant in the destination 497 address field of the IP packet header (i.e. the subnet mask in 498 slash notation). 500 Abstract Data Type: octet 502 Field Id: 13 504 Units: bits 506 4.14 egressInterface 508 Description: The index of the IP interface (ifIndex) where packets of 509 a flow are being sent. 511 Abstract Data Type: unsigned32 513 Data Type Semantics: identifier 515 Field Id: 14 517 Reference: See RFC 2863 for the definition of the ifIndex object. 519 4.15 ipNextHopAddressV4 521 Description: The IPv4 address of the next IP hop to which packets are 522 forwarded. 524 Abstract Data Type: ipv4Address 526 Field Id: 15 528 4.16 sourceAsNumber 530 Description: The autonomous system (AS) number of the source address 531 in the IP packet header. 533 Abstract Data Type: unsigned16 535 Data Type Semantics: identifier 537 Field Id: 16 539 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 540 definition of the AS number. 542 4.17 destinationAsNumber 544 Description: The autonomous system (AS) number of the destination 545 address in the IP packet header. 547 Abstract Data Type: unsigned16 549 Data Type Semantics: identifier 551 Field Id: 17 553 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 554 definition of the AS number. 556 4.18 bgpNextHopAddressV4 558 Description: The IPv4 address of the next BGP hop to which packets 559 are forwarded. 561 Abstract Data Type: ipv4Address 563 Data Type Semantics: identifier 565 Field Id: 18 567 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 568 definition of the AS number. 570 4.19 mcPacketsSent 572 Description: The number of sent multicast packets. 574 Abstract Data Type: unsigned64 576 Field Id: 19 578 Units: packets 580 4.20 mcOctetsSent 582 Description: The number of sent multicast octets. 584 Abstract Data Type: unsigned64 586 Field Id: 20 588 Units: octets 590 4.21 flowEndTime 592 Description: The timestamp of the last packet of a flow. 594 Abstract Data Type: dateTimeSeconds 596 Field Id: 21 598 4.22 flowCreationTime 600 Description: The timestamp of the first packet of a flow. 602 Abstract Data Type: dateTimeSeconds 604 Field Id: 22 606 4.23 sourceAddressV6 608 Description: IPv6 source address taken from the packet header. 610 Abstract Data Type: ipv6Address 612 Field Id: 27 614 4.24 destinationAddressV6 615 Description: IPv6 destination address taken from the packet header. 617 Abstract Data Type: ipv6Address 619 Field Id: 28 621 4.25 anotherSourceMask 623 Description: 625 The number of contiguous bits that are relevant in the source 626 address field of the IP packet header (i.e. the subnet mask in 627 slash notation). This redundant field has the same semantics as 628 field 9. 630 Abstract Data Type: octet 632 Field Id: 29 634 Units: bits 636 4.26 destinationMask 638 Description: 640 The number of contiguous bits that are relevant in the destination 641 address field of the IP packet header (i.e. the subnet mask in 642 slash notation). This redundant field has the same semantics as 643 field 13. 645 Abstract Data Type: octet 647 Field Id: 30 649 Units: bits 651 4.27 flowLabel 653 Description: The Flow Label of the IPv6 packet header. 655 Abstract Data Type: unsigned32 657 Field Id: 31 659 Reference: See RFC 2460 for a definition of the flow label field in 660 the IPv6 packet header. 662 4.28 icmpTypeCode 664 Description: Type and Code of the ICMP message. 666 Abstract Data Type: unsigned16 668 Field Id: 32 670 Reference: See RFC 792 for a definition of the ICMP type and code 671 fields. 673 4.29 igmpType 675 Description: The type field of the IGMP message. 677 Abstract Data Type: octet 679 Field Id: 33 681 Reference: See RFC 2236 for a definition of the IGMP type field. 683 4.30 samplingInterval 685 Description: 687 Number of packets received as a ratio of number of packets 688 sampled. For example a value of 100 would mean that one packet in 689 100 was sampled. EDITORS' NOTE: This will be replaced by the 690 PSAMP INFO MODEL 692 Abstract Data Type: unsigned32 694 Field Id: 34 696 Units: packets 698 4.31 samplingAlgorithm 700 Description: 702 The following sampling algorithms are defined: 704 * 1 Deterministic sampling 706 * 2 Random Sampling 707 * 3 Time-based sampling 709 EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL 711 Abstract Data Type: octet 713 Data Type Semantics: identifier 715 Field Id: 35 717 4.32 flowReportingInterval 719 Description: Interval between reports for an active flow. 721 Abstract Data Type: unsigned16 723 Field Id: 36 725 Units: seconds 727 4.33 flowIdleTimeout 729 Description: 731 A flow is considered to be timed out if not packet belonging to 732 the flow has been observed for the number of seconds specified by 733 this field. 735 Abstract Data Type: unsigned16 737 Field Id: 37 739 Units: seconds 741 4.34 exportedOctetCount 743 Description: The number of octets reported by the exporting process. 745 Abstract Data Type: unsigned64 747 Field Id: 40 749 Units: octets 751 4.35 exportedPacketCount 752 Description: The number of packets reported by the exporting process. 754 Abstract Data Type: unsigned64 756 Field Id: 41 758 Units: packets 760 4.36 exportedFlowCount 762 Description: The number of flows reported by the exporting process. 764 Abstract Data Type: unsigned64 766 Field Id: 42 768 Units: flows 770 4.37 ipVersion 772 Description: The IP version field given in the IP header. 774 Abstract Data Type: octet 776 Field Id: 60 778 Units: flows 780 Reference: 782 See RFC 791 for a definition of the version field in the IPv6 783 packet header. See RFC 2460 for a definition of the version field 784 in the IPv6 packet header. Additional information on defined 785 version numbers can be found at http://www.iana.org/assignments/ 786 version-numbers. 788 4.38 ipNextHopAddressV6 790 Description: The IPv6 address of the next IP hop to which packets are 791 forwarded. 793 Abstract Data Type: ipv6Address 795 Field Id: 62 797 4.39 bgpNextHopAddressV6 799 Description: The IPv6 address of the next BGP hop to which packets 800 are forwarded. 802 Abstract Data Type: ipv6Address 804 Data Type Semantics: identifier 806 Field Id: 63 808 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 809 definition of the AS number. 811 4.40 bgpNextHopAsNumber 813 Description: The autonomous system (AS) number of the next BGP hop 814 the packets are sent to. 816 Abstract Data Type: unsigned16 818 Data Type Semantics: identifier 820 Field Id: 80 822 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 823 definition of the AS number. 825 4.41 ipNextHopAsNumber 827 Description: The autonomous system (AS) number of the next IP hop the 828 packets are sent to. 830 Abstract Data Type: unsigned16 832 Data Type Semantics: identifier 834 Field Id: 81 836 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a 837 definition of the AS number. 839 4.42 exporterAddressV4 840 Description: 842 The IPv4 address of the flow exporter. This is used by the 843 collecter to identify the exporter in cases where the identity of 844 the exporter may have been obscured by the use of a proxy. 846 Abstract Data Type: ipv4Address 848 Field Id: 82 850 4.43 exporterAddressV6 852 Description: 854 The IPv6 address of the flow exporter. This is used by the 855 collecter to identify the exporter in cases where the identity of 856 the exporter may have been obscured by the use of a proxy. 858 Abstract Data Type: ipv4Address 860 Field Id: 83 862 4.44 droppedOctetCount 864 Description: The number of octets dropped. 866 Abstract Data Type: unsigned64 868 Field Id: 84 870 Units: octets 872 4.45 droppedPacketCount 874 Description: The number of packets dropped. 876 Abstract Data Type: unsigned64 878 Field Id: 84 880 Units: packets 882 4.46 flowEndReason 884 Description: The number of packets dropped. 886 * idle timeout 887 * end of flow detected (e.g. TCP FIN) 889 * forced end 891 * cache full 893 EDITORS' NOTE: This needs to be defined as an enumerated range. 895 Abstract Data Type: octet 897 Field Id: 84 899 5. Extending the Information Model 901 A key requirement for IPFIX is to allow for extending the set of 902 information items which are reported for flows. This section defines 903 the mechanism for extending this set. 905 The IPFIX protocol carries flow records defined by a template. 906 Multiple templates may be defined for a dialog between an exporter 907 and a collector. A given template identifies the information items 908 and their order. The means of identification of information items in 909 a template is via a field ID. Field Id's are unique identifiers 910 administered by IANA. 912 Extension is done by defining new Information elements, including the 913 set of necessary information and possibly additional optional 914 information for each element. Each new information item MUST be 915 assigned a unique fieldId as part of its definition. These unique 916 field ids are the connection between the record structure 917 communicated by the protocol using templates and a consuming 918 application. 920 Vendor specific extensions may be made by vendors with IANA 921 enterprise ID assignments, without registering specific field ID's 922 with IANA. In these cases the field definiton must specify the 923 vendor ID as well as the vendor-specified field ID and other 924 mandatory field properties. Before creating vendor-specific fields, 925 the general applicability of such information elements should be 926 considered. For generally applicable fields using IETF and IANA 927 mechanisms for extendind the information model is recommended. 929 6. IANA Considerations 931 IANA has to create a new registry for IPFIX fields ID's. 933 Appendix B defines an XML schema which may be used to create 934 consistent machine readable extensions to the IPFIX information 935 model. This schema introduces a new namaspace, which will be assigned 936 by IANA according to RFC 3688. Currently the name space for this 937 schema is identified as http://www.ietf.org/ipfix. 939 7. Security Considerations 941 The IPFIX information model itself does not directly introduce 942 security issues. Rather it defines a set of attributes which may for 943 privacy or business issues be considered sensitive information. 945 The underlying protocol used to exchange the information described 946 here must therefor apply appropriate procedures to guarantee the 947 integrity and confidentiality of the exported information. Such 948 protocols are defined in separate documents. Specifically the IPFIX 949 Protocol document. 951 8. Acknowledgements 953 The editors thank Stewart Bryant for a lot of useful input on the 954 field definitions. Also many thanks to Thomas Dietz for developing 955 the XSLT scripts that generate large portions of the text part of 956 this document from the XML appendices. 958 Normative Reference 960 [1] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX 961 Protocol Specification", IETF draft work in progress, January 962 2004, . 965 Informative Reference 967 [2] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements 968 for IP Flow Information Export", IETF draft work in progress, 969 January 2004, . 972 [3] Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow 973 Information Export", IETF draft work in progress, October 2003, 974 . 977 [4] Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX 978 Applicability", IETF draft work in progress, October 2003, 979 . 982 [5] Claise, B., "Cisco Systems NetFlow Services Export Version 9", 983 IETF draft work in progress, June 2003, . 986 [6] World Wide Web Consortium, "Extensible Markup Language (XML) 987 1.0", W3C XML, February 1998, . 990 [7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C 991 XML, May 2001, . 994 [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 995 XML, May 2001, . 998 [9] Internet Protocol Detail Record Organization, "Network Data 999 Management - Usage (NDM-U) For IP-Based Services Version 1000 3.1.1", October 2002, . 1003 [10] Brownlee, N. and A. Blount, "Accounting Attributes and Record 1004 Formats", RFC 2924, Sept. 2000, . 1007 [11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1008 1999, . 1010 [12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 1011 Use of Extensible Markup Language (XML) within IETF Protocols", 1012 RFC 3470, January 2003, . 1014 [13] Pras, A. and J. Schoenwaelder, "On the Difference between 1015 Information Models and Data Models", RFC 3444, January 2003, 1016 . 1018 [14] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004, 1019 . 1021 Authors' Addresses 1023 Paul Calato 1024 Riverstone Networks Inc 1025 5200 Great America Parkway 1026 Santa Clara, CA 95054 1027 US 1029 Phone: +1 603 557-6913 1030 EMail: calato@riverstonenet.com 1031 URI: http://www.riverstonenet.com 1033 Jeff Meyer 1034 PayPal 1035 2211 N. First St. 1036 San Jose, CA 95131-2021 1037 US 1039 Phone: +1 408 976-9149 1040 EMail: jemeyer@paypal.com 1041 URI: http://www.paypal.com 1043 Juergen Quittek 1044 NEC Europe Ltd. 1045 Kurfuersten-Anlage 36 1046 Heidelberg 69115 1047 Germany 1049 Phone: +49 6221 90511-15 1050 EMail: quittek@netlab.nec.de 1051 URI: http://www.netlab.nec.de/ 1053 Appendix A. Formal Specification of IPFIX Fields 1055 This appendix contains a formal description of the IPFIX information 1056 model XML document. Note that this appendix is of informational 1057 nature, while the text in section 4 generated from this appendix is 1058 normative. 1060 Using a formal and machine readable syntax for the Information model 1061 enables the creation of IPFIX aware tools which can automatically 1062 adapt to extensions to the information model, by simply reading 1063 updated information model specifications. 1065 The wide availability of XML aware tools and libraries for client 1066 devices is a primary consideration for this choice. In particular 1067 libraries for parsing XML documents are readily available. Also 1068 mechanisms such as the Extensible Stylesheet Language (XSL) allow for 1069 transforming a source XML document into other documents. This draft 1070 was authored in XML and transformed according to RFC2629. 1072 It should be noted that the use of XML in exporters, collectors or 1073 other tools is not mandatory for the deployment of IPFIX. In 1074 particular exporting processes do not produce or consume XML as part 1075 of their operation. It is expected that IPFIX collectors MAY take 1076 advantage of the machine readability of the Information Model vs. 1077 hardcoding their behavior or inventing proprietary means for 1078 accomodating extensions. 1080 1081 1083 1085 1086 The number of observed octets. 1087 1088 octets 1089 1091 1093 1094 The number of observed packets. 1095 1096 packets 1097 1099 1101 1102 The number of (aggregated) flows. 1103 1104 flows 1105 1107 1110 1111 1112 The protocol number that identifies the IP packet payload. 1113 Protocol numbers are defined in the IANA Protocol Numbers 1114 registry. 1116 1117 In Internet Protocol version 4 (IPv4) this is carried 1118 in the "Protocol" field. In Internet Protocol version 6 1119 (IPv6) this is carried in the "Next Header" field. 1120 1121 1122 1123 See RFC 791 for the specification of the IPv4 protocol field. 1124 See RFC 1883 for the specification of the IPv6 protocol field. 1125 See list of protocol numbers assigned by IANA at 1126 http://www.iana.org/assignments/protocol-numbers. 1127 1128 1129 1131 1134 1135 1136 The class of service. 1137 1139 1140 The definition of classOfService is dependent on the protocol 1141 being observed. Those considered here are: 1142 1143 1144 For IPv4 packets the class of service is given by the 1145 value of the type of service field in the IPv4 packet 1146 header. 1147 For IPv6 packets the class of service is given by the 1148 value of the traffic class field in the IPv6 packet 1149 header. 1150 For MPLS the class of service is given by the value of 1151 the experimental use (Exp) field in label stack entries. 1152 The Exp field has a length of 3 bits. These are mapped 1153 to the three least valued bits of the classOfService 1154 octet. All other bits of the octet are set to 1155 zero. 1156 For VLAN the class of service is given by the value 1157 of the type of the user_priority field as defined 1158 in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]. 1159 1161 EDITORS' NOTE: THIS NEEDS FURTHER WORK 1162 1163 1164 1165 See RFC 791 for the definition of the IPv4 TOS field. 1166 See RFC 2460 for the definition of the IPv6 traffic class 1167 field. 1168 See RFC 3032 for the definition of the Exp field in label stack 1169 entries. 1170 See IEEE802.1q and IEEE 802.1p for the definition of the VLAN 1171 user_priority field. 1172 1173 1174 1176 1179 1180 1181 The TCP control bits seen for this flow. Note that a 0 value 1182 for each bit only indicates that the flag was not detected 1183 (i.e. it may have occurred but was not detected by the 1184 reporting CCE). 1185 1187 EDITORS' NOTE: THIS NEEDS FURTHER WORK. 1188 The bit mapping needs to be specified. 1189 1190 See RFC 793 for a definiton of the TCP control bits 1191 in the TCP header. 1192 1194 1197 1198 A source port number in the UDP or TCP header, respectively. 1199 1200 1201 1202 See RFC 768 for the definiton of the UDP source port field. 1203 See RFC 793 for the definiton of the TCP source port field. 1204 Additional information on defined UDP and TCP port numbers 1205 can be found at http://www.iana.org/assignments/port-numbers. 1206 1207 1208 1210 1212 1213 The IPv4 source address in the IPv4 packet header. 1214 1215 1216 See RFC 791 for the definition of the IPv4 source address 1217 field. 1218 1219 1221 1223 1224 The number of contiguous bits that are relevant in the source 1225 address field of the IP packet header 1226 (i.e. the subnet mask in slash notation). 1227 1228 bits 1229 1231 1234 1235 The index of the IP interface (ifIndex) where packets of a flow 1236 are being received. 1237 1238 1239 See RFC 2863 for the definition of the ifIndex object. 1240 1241 1243 1246 1247 A destination port number in the UDP or TCP header, 1248 respectively. 1249 1250 1251 1252 See RFC 768 for the definiton of the UDP destination port 1253 field. 1254 See RFC 793 for the definiton of the TCP destination port 1255 field. 1256 Additional information on defined UDP and TCP port numbers 1257 can be found at http://www.iana.org/assignments/port-numbers. 1258 1259 1260 1262 1264 1265 The IPv4 destination address in the IPv4 packet header. 1266 1267 1268 See RFC 791 for the definition of the IPv4 destination address 1269 field. 1270 1271 1273 1275 1276 1277 The number of contiguous bits that are relevant in the 1278 destination address field of the IP packet header 1279 (i.e. the subnet mask in slash notation). 1280 1281 1282 bits 1283 1285 1288 1289 The index of the IP interface (ifIndex) where packets of a flow 1290 are being sent. 1291 1292 1293 See RFC 2863 for the definition of the ifIndex object. 1294 1295 1297 1299 1300 The IPv4 address of the next IP hop to which packets are 1301 forwarded. 1302 1303 1305 1308 1309 The autonomous system (AS) number of the source address in 1310 the IP packet header. 1311 1312 1313 See RFC 1771 for a description of BGB-4 and 1314 see RFC 1930 a definition of the AS number. 1315 1316 1318 1321 1322 The autonomous system (AS) number of the destination address 1323 in the IP packet header. 1324 1325 1326 See RFC 1771 for a description of BGB-4 and 1327 see RFC 1930 a definition of the AS number. 1328 1329 1331 1334 1335 The IPv4 address of the next BGP hop to which packets are 1336 forwarded. 1337 1338 1339 See RFC 1771 for a description of BGB-4 and 1340 see RFC 1930 a definition of the AS number. 1341 1342 1344 1346 1347 The number of sent multicast packets. 1348 1349 packets 1350 1352 1354 1355 The number of sent multicast octets. 1356 1357 octets 1358 1360 1362 1363 The timestamp of the last packet of a flow. 1364 1365 1367 1369 1370 The timestamp of the first packet of a flow. 1371 1372 1374 1376 1377 IPv6 source address taken from the packet header. 1378 1379 1381 1383 1384 IPv6 destination address taken from the packet header. 1385 1386 1387 1389 1390 1391 The number of contiguous bits that are relevant in the source 1392 address field of the IP packet header (i.e. the subnet mask 1393 in slash notation). This redundant field has the same 1394 semantics as field 9. 1395 1396 1397 bits 1398 1400 1402 1403 1404 The number of contiguous bits that are relevant in the 1405 destination address field of the IP packet header (i.e. the 1406 subnet mask in slash notation). This redundant field has 1407 the same semantics as field 13. 1408 1409 1410 bits 1411 1413 1415 1416 The Flow Label of the IPv6 packet header. 1417 1418 1419 See RFC 2460 for a definition of the flow label field in the 1420 IPv6 packet header. 1421 1422 1424 1426 1427 Type and Code of the ICMP message. 1428 1429 1430 See RFC 792 for a definition of the ICMP type and code fields. 1431 1432 1434 1436 1437 The type field of the IGMP message. 1438 1439 1440 See RFC 2236 for a definition of the IGMP type field. 1441 1442 1444 1446 1447 1448 Number of packets received as a ratio of number of packets 1449 sampled. For example a value of 100 would mean that one packet 1450 in 100 was sampled. 1451 1453 EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL 1454 1455 packets 1456 1458 1461 1462 1463 The following sampling algorithms are defined: 1464 1466 1467 1 Deterministic sampling 1468 2 Random Sampling 1469 3 Time-based sampling 1470 1472 EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL 1473 1474 1476 1478 1479 Interval between reports for an active flow. 1480 1481 seconds 1482 1483 1485 1486 1487 A flow is considered to be timed out if not packet 1488 belonging to the flow has been observed for the number 1489 of seconds specified by this field. 1490 1491 1492 seconds 1493 1495 1497 1498 The number of octets reported by the exporting process. 1499 1500 octets 1501 1503 1505 1506 The number of packets reported by the exporting process. 1507 1508 packets 1509 1511 1513 1514 The number of flows reported by the exporting process. 1515 1516 flows 1517 1519 1521 1522 The IP version field given in the IP header. 1523 1524 flows 1525 1526 1527 See RFC 791 for a definition of the version field in the 1528 IPv6 packet header. 1529 See RFC 2460 for a definition of the version field in the 1530 IPv6 packet header. 1532 Additional information on defined version numbers 1533 can be found at 1534 http://www.iana.org/assignments/version-numbers. 1535 1536 1537 1539 1541 1542 The IPv6 address of the next IP hop to which packets are 1543 forwarded. 1544 1545 1547 1550 1551 The IPv6 address of the next BGP hop to which packets are 1552 forwarded. 1553 1554 1555 See RFC 1771 for a description of BGB-4 and 1556 see RFC 1930 a definition of the AS number. 1557 1558 1560 1563 1564 The autonomous system (AS) number of the next BGP hop the 1565 packets are sent to. 1566 1567 1568 See RFC 1771 for a description of BGB-4 and 1569 see RFC 1930 a definition of the AS number. 1570 1571 1573 1576 1577 The autonomous system (AS) number of the next IP hop the 1578 packets are sent to. 1579 1580 1581 See RFC 1771 for a description of BGB-4 and 1582 see RFC 1930 a definition of the AS number. 1583 1584 1586 1588 1589 1590 The IPv4 address of the flow exporter. This is used by the 1591 collecter to identify the exporter in cases where the identity 1592 of the exporter may have been obscured by the use of a proxy. 1593 1594 1595 1597 1599 1600 1601 The IPv6 address of the flow exporter. This is used by the 1602 collecter to identify the exporter in cases where the identity 1603 of the exporter may have been obscured by the use of a proxy. 1604 1605 1606 1608 1610 1611 The number of octets dropped. 1612 1613 octets 1614 1616 1618 1619 The number of packets dropped. 1620 1621 packets 1622 1624 1626 1627 The number of packets dropped. 1629 1630 idle timeout 1631 end of flow detected (e.g. TCP FIN) 1632 forced end 1633 cache full 1634 1635 EDITORS' NOTE: This needs to be defined as an 1636 enumerated range. 1637 1638 1640 1642 Appendix B. Formal Specification of Abstract Data Types 1644 This appendix containfs a formal description of the abstract data 1645 types to be used for IPFIX fields and a formal description of the 1646 template used for defining IPFIX fields. Note that this appendix is 1647 of informational nature, while the text in sections 2 and 3 generated 1648 from this appendix is normative. 1650 1651 1655 1656 1657 1658 1659 The type "unsignedByte" represents a 1660 non-negative integer value in the range of 0 to 255. 1661 1662 1663 1665 1666 1667 The type "unsigned16" represents a 1668 non-negative integer value in the range of 0 to 65535. 1669 1670 1671 1673 1674 1675 The type "unsigned32" represents a 1676 non-negative integer value in the range of 0 to 1677 4294967295. 1678 1679 1680 1682 1683 1684 The type "unsigned64" represents a 1685 non-negative integer value in the range of 0 to 1686 18446744073709551615. 1687 1688 1690 1692 1693 1694 The type "float32" corresponds to an IEEE 1695 single-precision 32-bit floating point type. 1696 1697 1698 1700 1701 1702 The type "boolean" represents a binary 1703 value. 1704 1705 1706 1708 1709 1710 The type "octetArray" represents a finite 1711 length string of octets. 1712 1713 1714 1716 1717 1718 1719 The type "string" represents a finite length string 1720 of valid characters from the Unicode character 1721 encoding set. Unicode allows for ASCII and many 1722 other international character sets to be used. 1723 It is expected that strings will be encoded in UTF-8 1724 format, which is identical in encoding for USASCII 1725 characters, but also accomodates other Unicode 1726 multibyte characters. 1727 1728 1729 1731 1732 1733 1734 The type "dateTimeSeconds" represents a time value 1735 having a precision of seconds and normalized to the 1736 GMT timezone. Such types are in common use on many 1737 operating systems and have the advantage that they 1738 can be stored in 32-bit integers. 1739 1740 1741 1743 1744 1745 The type "dateTimeSeconds" represents a 1746 time value having a precision of microseconds and 1747 normalized to the GMT timezone. 1748 1749 1750 1752 1753 1754 The type "ipv4Addr" represents a value of 1755 an IPv4 address. These addresses are typically stored 1756 as 32-bit integers. 1757 1758 1759 1761 1762 1763 The type "ipv6Addr" represents a value 1764 of an IPv6 address. 1765 1766 1767 1768 1769 1771 1772 1773 1774 1775 1776 A quantity value represents a discrete 1777 measured value pertaining to the record. This is 1778 distinguished from counters which represent an ongoing 1779 measured value whose "odometer" reading is captured as 1780 part of a given record. If no semantic qualifier is 1781 given, the integral fields should behave as a quantity. 1782 1783 1784 1785 1786 1787 1788 A measurement which is ongoing from the perspective 1789 of the exporter. Basically the same semantics as 1790 counters in SNMP. Counters are unsigned and wrap back 1791 to zero after reaching the limit of the type. E.g. an 1792 unsigned64 with counter semantics will continue to 1793 increment until reaching the value of 2**64 - 1. 1794 At this point the next increment will wrap its value 1795 to zero and continue counting from zero. 1796 1797 1798 1800 1801 1802 1803 An integral value which serves as an identifier. 1804 Specifically mathematical operations on two 1805 identifiers (aside from the equality operation) are 1806 meaningless. E.g. Autonomous System Id 1 * Autonomous 1807 System Id 2 is meaningless. 1808 1809 1810 1812 1813 1814 1815 An integral value which actually represents a set of 1816 bit fields. Logical operations are appropriate on 1817 such values, but not other mathematical operations. 1818 Flags should always be of an unsigned type. 1819 1820 1821 1822 1823 1825 1826 1827 1828 1829 1830 Used for fields that are applicable to flow records 1831 only. 1832 1834 1835 1837 1838 1839 1840 Used for fields that are applicable to option records 1841 only. 1842 1843 1844 1846 1847 1848 1849 Used for fields that are applicable to flow records 1850 as well as to option records. 1851 1852 1853 1854 1855 1857 1858 1859 1860 1861 1862 Indicates that the field definition is that the 1863 definition is current and valid. 1864 1865 1866 1868 1869 1870 1871 Indicates that the field definition is obsolete, but 1872 it permits new/continued implementation in order to 1873 foster interoperability with older/existing 1874 implementations. 1875 1876 1877 1879 1880 1881 1882 Indicates that the field definition is obsolete and 1883 should not be implemented and/or can be removed if 1884 previously implemented. 1885 1886 1887 1888 1889 1891 1892 1893 1895 1896 1897 1899 1900 1901 1903 1904 to be done ... 1905 1906 1907 1908 1910 1911 1912 1914 1915 to be done ... 1916 1917 1918 1920 1921 to be done ... 1922 1923 1924 1925 1927 1928 1929 1930 1931 1932 1933 1935 1936 1937 The semantics of this information element. 1938 Describes how this field is derived from the 1939 flow or other information available to the 1940 observer. 1941 1942 1943 1945 1947 1948 to be done ... 1949 1950 1952 1954 1955 1956 If the field is a measure of some kind, the 1957 units identify what the measure is. 1958 1959 1960 1962 1964 1965 1966 Identifies additional specifications which more 1967 precisely define this item or provide additional 1968 context for its use. 1969 1970 1971 1973 1975 1976 1977 Some items may have a specific set of numeric 1978 identifiers associated with a set of discrete 1979 values this element may take. The meaning of 1980 each discrete value and a human readable name 1981 should be assigned. 1982 1983 1984 1986 1988 1989 1990 Some elements may only be able to take on a 1991 restricted set of values which can be 1992 expressed as a range (e.g. 0 through 511 1993 inclusive). If this is the case, the valid 1994 inclusive range should be specified. 1995 1996 1997 1998 2000 2001 2002 2003 A unique and meaningful name for the field. The 2004 preferred spelling for the name is to use mixed 2005 case if the name is compound, with an initial 2006 lower case letter. (E.g. "sourceIpAddress"). 2007 2008 2009 2011 2013 2014 2015 One of the types listed in the "Type Space" 2016 section. The type space for attributes is 2017 constrained to facilitate implementation. 2018 The existing type space does however encompass 2019 most basic types used in modern programming 2020 languages, as well as some derived types 2021 (such as IPAddress) which are common to this 2022 domain and useful to distinguish. 2023 2024 2025 2026 2028 2029 2030 The integral types may be qualified by additional 2031 semantic details. Qualifying the fields as 2032 'quantity', 'counter', 'identifier' or 'flags'. 2033 2034 2035 2037 2039 2040 2041 A numeric identifier administered by IANA. 2042 This is used for compact identification of an 2043 information item when encoding templates in the 2044 protocol. 2045 2046 2047 2049 2051 2052 2053 When extension is done outside of the scope of 2054 the IANA IPFIX fieldId range, a vendorId MUST 2055 be provided. This identifier is based on IANA 2056 assigned enterprise identifiers. 2057 2058 2059 2061 2063 2064 to be done ... 2065 2066 2068 2070 2071 to be done ... 2072 2073 2075 2076 2077 2078 2080 2081 2083 2084 2085 2086 2088 Intellectual Property Statement 2090 The IETF takes no position regarding the validity or scope of any 2091 intellectual property or other rights that might be claimed to 2092 pertain to the implementation or use of the technology described in 2093 this document or the extent to which any license under such rights 2094 might or might not be available; neither does it represent that it 2095 has made any effort to identify any such rights. Information on the 2096 IETF's procedures with respect to rights in standards-track and 2097 standards-related documentation can be found in BCP-11. Copies of 2098 claims of rights made available for publication and any assurances of 2099 licenses to be made available, or the result of an attempt made to 2100 obtain a general license or permission for the use of such 2101 proprietary rights by implementors or users of this specification can 2102 be obtained from the IETF Secretariat. 2104 The IETF invites any interested party to bring to its attention any 2105 copyrights, patents or patent applications, or other proprietary 2106 rights which may cover technology that may be required to practice 2107 this standard. Please address the information to the IETF Executive 2108 Director. 2110 Full Copyright Statement 2112 Copyright (C) The Internet Society (2004). All Rights Reserved. 2114 This document and translations of it may be copied and furnished to 2115 others, and derivative works that comment on or otherwise explain it 2116 or assist in its implementation may be prepared, copied, published 2117 and distributed, in whole or in part, without restriction of any 2118 kind, provided that the above copyright notice and this paragraph are 2119 included on all such copies and derivative works. However, this 2120 document itself may not be modified in any way, such as by removing 2121 the copyright notice or references to the Internet Society or other 2122 Internet organizations, except as needed for the purpose of 2123 developing Internet standards in which case the procedures for 2124 copyrights defined in the Internet Standards process must be 2125 followed, or as required to translate it into languages other than 2126 English. 2128 The limited permissions granted above are perpetual and will not be 2129 revoked by the Internet Society or its successors or assignees. 2131 This document and the information contained herein is provided on an 2132 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2133 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2134 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2135 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2136 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2138 Acknowledgment 2140 Funding for the RFC Editor function is currently provided by the 2141 Internet Society.