idnits 2.17.1 draft-boschi-ipfix-extended-type-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 666. 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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 27, 2007) is 6120 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 (-26) exists of draft-ietf-ipfix-protocol-24 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group E. Boschi 3 Internet-Draft Hitachi Europe 4 Intended status: Standards Track B. Trammell 5 Expires: December 29, 2007 CERT/NetSA 6 L. Mark 7 T. Zseby 8 Fraunhofer FOKUS 9 June 27, 2007 11 Extended Type Information for IPFIX Enterprise-Specific Information 12 Elements 13 draft-boschi-ipfix-extended-type-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 29, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes an extension to IPFIX to provide type 47 information for enterprise-specific Information Elements. This 48 format is designed to facilitate interoperability and reusability 49 among a wide variety of applications and tools. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Type Information Extension . . . . . . . . . . . . . . . . . . 3 56 3.1. informationElementId . . . . . . . . . . . . . . . . . . . 4 57 3.2. informationElementSemanticType . . . . . . . . . . . . . . 4 58 3.3. informationElementStorageType . . . . . . . . . . . . . . 5 59 3.4. privateEnterpriseNumber . . . . . . . . . . . . . . . . . 6 60 3.5. Information Element Semantics Options Template . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 68 Appendix B. XML Specification of Extended Type Information 69 Elements . . . . . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 17 73 1. Introduction 75 The IPFIX protocol specification allows the creation of enterprise- 76 specific Information Elements to easily extend the protocol to meet 77 requirements which aren't covered by the existing Information Model. 78 However, there is no current mechanism to provide the data type for a 79 given Information Element (e.g. enterprise-specific ones). 81 In this situation, it will not be possible to use any existing 82 analysis tool on IPFIX records containing enterprise-specific 83 Information Elements, since the tools will not be able to decode 84 these Information Elements. Having to do some sort of tool-specific 85 configuration (or code modification) on every tool just to tell which 86 type each used Information Element has is a huge amount of work for 87 users and implementors of enterprise-specific Information Eelements. 88 Many tools in fact only need to know the field's data type to work on 89 them. This memo specifies a mechanism for users to provide the data 90 type of an Information Elements in a standardized, automatable way. 92 This memo specifies a mechanism for exporters to provide the data 93 type and semantic information of enterprise-specific Information 94 Elements within the exported data stream in a standardized and 95 automatable way. We propose a mechanism, which makes use of IPFIX 96 Options Records to allow the mapping from (enterpriseID,Information 97 Element) pairs to corresponding data type and semantic information. 98 Including the information inline allows more rapid processing of the 99 data, and allows the flow stream (or file) to be partially self- 100 describing. 102 2. Terminology 104 Terms used in this document that are defined in the Terminology 105 section of the IPFIX Protocol [I-D.ietf-ipfix-protocol] document are 106 to be interpreted as defined there. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Type Information Extension 114 IPFIX Templates contain ID and length values but lack type and 115 semantic information. There is no standard method to get this 116 information for enterprise-specific Information Elements. A 117 Collecting Process receiving data described by a Template containing 118 unknown enterprise-specific Information Elements can only treat those 119 data as octet arrays. To be fully self-describing, enterprise- 120 specific Information Elements must be additionally described via 121 IPFIX Options according to the Information Element Semantics Options 122 Template defined below. 124 In this section we first specify the necessary Information Elements 125 for describing type information, and then the Information Element 126 Semantics Options Template. 128 3.1. informationElementId 130 Description: An information element ID, as would appear in an IPFIX 131 Template Record. This element can be used to scope properties to 132 a specific information element within a Template. This IE should 133 be encoded with the Enterprise ID bit set to 0, regardless of 134 whether the Enterprise ID bit is set in the template to which this 135 IE refers. See the definition of privateEnterpriseNumber below 136 for more on the use of this IE to describe vendor-specific IEs. 138 Abstract Data Type: unsigned16 140 Data Type Semantics: identifier 142 ElementId: TBD1 144 Status: Proposed 146 Reference: Section 3.4.1 of the IPFIX Protocol draft 148 3.2. informationElementSemanticType 150 Description: A description of the semantics of an IPFIX information 151 element within a template. These correspond to the data type 152 semantics defined in section 3.2 of the IPFIX Information Model 153 [I-D.ietf-ipfix-info]; see that section for more information on 154 the types described below. This field may take the following 155 values; the special value 0x00 (none) is used to note that no 156 semantics apply to the field; it cannot be manipulated by a 157 Collecting Process or File Reader that does not understand it a 158 priori. 160 +-------+--------------+ 161 | Value | Description | 162 +-------+--------------+ 163 | 0x00 | none | 164 | 0x01 | quantity | 165 | 0x02 | totalCounter | 166 | 0x03 | deltaCounter | 167 | 0x04 | identifier | 168 | 0x05 | flags | 169 +-------+--------------+ 171 Abstract Data Type: unsigned8 173 ElementId: TBD2 175 Status: Proposed 177 3.3. informationElementStorageType 179 Description: A description of the storage type of an IPFIX 180 information element within a template. These correspond to the 181 abstract data types defined in section 3.1 of the IPFIX 182 Information Model [I-D.ietf-ipfix-info]; see that section for more 183 information on the types described below. This field may take the 184 following values: 186 +-------+----------------------+ 187 | Value | Description | 188 +-------+----------------------+ 189 | 0x00 | octetArray | 190 | 0x01 | unsigned8 | 191 | 0x02 | unsigned16 | 192 | 0x03 | unsigned32 | 193 | 0x04 | unsigned64 | 194 | 0x05 | signed8 | 195 | 0x06 | signed16 | 196 | 0x07 | signed32 | 197 | 0x08 | signed64 | 198 | 0x09 | float32 | 199 | 0x0A | float64 | 200 | 0x0B | boolean | 201 | 0x0C | macAddress | 202 | 0x0D | string | 203 | 0x0E | dateTimeSeconds | 204 | 0x0F | dateTimeMilliseconds | 205 | 0x10 | dateTimeMicroseconds | 206 | 0x11 | dateTimeNanoseconds | 207 | 0x12 | ipv4Address | 208 | 0x13 | ipv6Address | 209 +-------+----------------------+ 211 Abstract Data Type: unsigned8 213 ElementId: TBD3 215 Status: Proposed 217 Reference: Section 3.1 of the IPFIX Information Model 219 3.4. privateEnterpriseNumber 221 Description: A private enterprise number used to scope an 222 information element ID, as would appear in an IPFIX Template 223 Record. This element can be used to scope properties to a 224 specific information element within a Template. If the Enterprise 225 ID bit of the corresponding Information Element is cleared (has 226 the value 0), this IE should be set to 0. The presence of a non- 227 zero value in this IE implies that the Enterprise ID bit of the 228 corresponding Information Element is set (has the value 1). 230 Abstract Data Type: unsigned32 231 Data Type Semantics: identifier 233 ElementId: TBD4 235 Status: Proposed 237 Reference: Section 3.4.1 of the IPFIX Protocol draft 239 3.5. Information Element Semantics Options Template 241 The Information Element Semantics Options Template specifies the 242 structure of a Data Record for attaching semantic and storage type 243 information to Enterprise Specific Information Elements in specified 244 Template Records. Data Records described by this template are 245 referred to as Information Element semantics records. 247 In deployments in which interoperability across vendor 248 implementations of IPFIX is important, an Exporting Process exporting 249 data using Templates containing enterprise-specific Information 250 Elements SHOULD export an Information Element semantics record for 251 each enterprise-specific Information Element it exports. Collecting 252 Processes MAY use these semantics records to improve handling of 253 unknown enterprise-specific Information Elements. Exporting 254 Processes using enterprise-specific Information Elements to implement 255 proprietary features MAY omit semantics records for those Information 256 ELements. 258 Information Element semantics records MUST be handled by Collecting 259 Processes as scoped to the Transport Session in which they are sent; 260 this facility is not intended to provide a method for the permanent 261 definition of Information Elements. 263 Similarly, for security reasons, storage and semantics types for a 264 given Information Element MUST NOT be re-defined by Information 265 Element semantics records. Once an Information Element semantics 266 record has been exported for a given Information Element within a 267 given Transport Session, all subsequent semantics records for that 268 Information Element MUST be identical. If conflicting semantic or 269 type information is received in multiple semantics records by a 270 Collecting Process, the Collecting Process MUST reset the Transport 271 Session. 273 Information Element semantics records MUST NOT be used to define 274 semantics for IANA registered Information Elements (private 275 enterprise number (PEN) 0) or for PENs with a special meaning within 276 the IPFIX Protocol (e.g., the Reverse PEN from Bidirectional Flow 277 Export using IPFIX [I-D.ietf-ipfix-biflow]). 279 The template SHOULD contain the following Information Elements as 280 defined in the IPFIX Information Model [I-D.ietf-ipfix-info] and 281 above: 283 +--------------------------------+----------------------------------+ 284 | IE | Description | 285 +--------------------------------+----------------------------------+ 286 | informationElementID | The Information Element | 287 | | identifier of the Information | 288 | | Element within the specified | 289 | | Template this record describes. | 290 | | This Information Element MUST be | 291 | | defined as a Scope Field. | 292 | privateEnterpriseNumber | The Private Enterprise number of | 293 | | the Information Element within | 294 | | the specified Template this | 295 | | record describes. This | 296 | | Information Element MUST be | 297 | | defined as a Scope Field. | 298 | informationElementStorageType | The storage type of the | 299 | | specified Information Element. | 300 | informationElementSemanticType | The semantic type of the | 301 | | specified Information Element. | 302 +--------------------------------+----------------------------------+ 304 4. Security Considerations 306 The same security considerations as for the IPFIX Protocol 307 [I-D.ietf-ipfix-protocol] apply. 309 5. IANA Considerations 311 This document specifies the creation of four new IPFIX Information 312 Elements as described in sections 4.1 through 4.4. IANA has assigned 313 the IPFIX Information Element number TBD1 in the IPFIX Information 314 Element registry for the informationElementId Information Element; 315 the IPFIX Information Element number TBD2 in the IPFIX Information 316 Element registry for the informationElementSemanticType Information 317 Element; the IPFIX Information Element number TBD3 in the IPFIX 318 Information Element registry for the informationElementStorageType 319 Information Element; and the IPFIX Information Element number TBD4 in 320 the IPFIX Information Element registry for the 321 privateEnterpriseNumber Information Element. 323 [NOTE for IANA: The text TBD1 should be replaced with the assigned 324 informationElementId Information Element number where it appears in 325 this document. The text TBD2 should be replaced with the assigned 326 informationElementSemanticType Information Element number where it 327 appears in this document. The text TBD3 should be replaced with the 328 assigned informationElementStorageType Information Element number 329 where it appears in this document. The text TBD4 should be replaced 330 with the assigned privateEnterpriseNumber Information Element number 331 where it appears in this document.] 333 In addition, IANA has created an Information Element Semantic Type 334 subregistry for the values defined for the 335 informationElementSemanticType Information Element in section 4.2. A 336 specification is required to add entries to this subregistry; new 337 values and their meaning must be documented in an RFC or other 338 permanent and readily available reference. 340 [NOTE for IANA: Please create a new Information Element Semantic Type 341 subregistry as specified in the paragraph above, with initial values 342 taken from section 4.2 of this document.] 344 6. Acknowledgements 346 Thanks to David Moore for first raising this issue to the IPFIX 347 mailing list. 349 7. References 351 7.1. Normative References 353 [I-D.ietf-ipfix-protocol] 354 Claise, B., "Specification of the IPFIX Protocol for the 355 Exchange", draft-ietf-ipfix-protocol-24 (work in 356 progress), November 2006. 358 [I-D.ietf-ipfix-info] 359 Quittek, J., "Information Model for IP Flow Information 360 Export", draft-ietf-ipfix-info-15 (work in progress), 361 February 2007. 363 7.2. Informative References 365 [I-D.ietf-ipfix-biflow] 366 Trammell, B. and E. Boschi, "Bidirectional Flow Export 367 using IPFIX", draft-ietf-ipfix-biflow-05 (work in 368 progress), June 2007. 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 Appendix A. Examples 375 The following example illustrates how the type information extension 376 mechanism defined in this document may be used to describe the 377 semantics of enterprise-specific Information Elements. The 378 Information Elements used in this example are as follows: 380 o initialTCPFlags, CERT (PEN 6871) private IE 14, 1 octet, the TCP 381 flags on the first TCP packet in the flow. 383 o unionTCPFlags, CERT (PEN 6871) private IE 15, 1 octet, the union 384 of the TCP flags on all packets after the first TCP packet in the 385 flow. 387 An Exporting Process exporting flows containing these Information 388 Elements might use a Template like the following: 390 1 2 3 391 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Set ID = 2 | Length = 52 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Template ID = 256 | Field Count = 9 | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 |0| flowStartSeconds 150 | Field Length = 4 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |0| sourceIPv4Address 8 | Field Length = 4 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |0| destinationIPv4Address 12 | Field Length = 4 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |0| sourceTransportPort 7 | Field Length = 2 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |0| destinationTransportPort 11 | Field Length = 2 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |0| octetTotalCount 85 | Field Length = 4 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |1| (initialTCPFlags) 14 | Field Length = 1 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | PEN 6871 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |1| (unionTCPFlags) 15 | Field Length = 1 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | PEN 6871 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |0| protocolIdentifier 4 | Field Length = 1 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 1: Template with Enterprise-Specific IEs 422 However, a Collecting Process receiving Data Sets described by this 423 Template can only treat the enterprise-specific Information Elements 424 as opaque octets; specifically, there is no hint to the collector 425 that they contain flag informartion. To use the type information 426 extension mechanism to address this problem, the Exporting Process 427 would first export the Information Element Semantics Options Template 428 described in section 4.5, above: 430 1 2 3 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Set ID = 3 | Length = 26 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Template ID = 257 | Field Count = 4 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Scope Field Count = 2 |0| priv.EnterpriseNumber TBD4 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Field Length = 4 |0| informationElementId TBD1 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Field Length = 2 |0| inf.El.StorageType TBD3 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Field Length = 1 |0| inf.El.SemanticType TBD2 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Field Length = 1 | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Figure 2: Example Information Element Semantics Options Template 450 Then, the Exporting Process would then export two records described 451 by the Example Information Element Semantics Options Template to 452 describe the enterprise-specific Information Elements: 454 1 2 3 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Set ID = 257 | Length = 20 | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | PEN 6871 | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | IE 14 |0x01 unsigned8 |0x05 flags | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | PEN 6871 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | IE 15 |0x01 unsigned8 |0x05 flags | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 3: Type Information Extension Example 470 Appendix B. XML Specification of Extended Type Information Elements 472 This appendix contains a machine-readable description of the 473 Information Elements defined in this document, coded in XML. Note 474 that this appendix is of informational nature, while the text in 475 section 3 is normative. 477 The format in which this specification is given is described by the 478 XML Schema in Appendix B of the IPFIX Information Model 479 [I-D.ietf-ipfix-info]. 481 483 488 491 492 493 An information element ID, as would appear in an IPFIX Template 494 Record. This element can be used to scope properties to a specific 495 information element within a Template. This IE should be encoded with 496 the Enterprise ID bit set to 0, regardless of whether the Enterprise 497 ID bit is set in the template to which this IE refers. See the 498 definition of privateEnterpriseNumber below for more on the use of 499 this IE to describe vendor-specific IEs. 500 501 502 504 507 508 509 A description of the semantics of an IPFIX information element within 510 a template. These correspond to the data type semantics defined in 511 section 3.2 of the IPFIX Information Model; see that section for more 512 information on the types described below. This field may take the 513 following values; the special value 0x00 (none) is used to note that 514 no semantics apply to the field; it cannot be manipulated by a 515 Collecting Process or File Reader that does not understand it a 516 priori. 517 518 519 +-------+--------------+ 520 | Value | Description | 521 +-------+--------------+ 522 | 0x00 | none | 523 | 0x01 | quantity | 524 | 0x02 | totalCounter | 525 | 0x03 | deltaCounter | 526 | 0x04 | identifier | 527 | 0x05 | flags | 528 +-------+--------------+ 529 530 531 533 536 537 538 A description of the storage type of an IPFIX information element 539 within a template. These correspond to the abstract data types defined 540 in section 3.1 of the IPFIX Information Model; see that section for 541 more information on the types described below. This field may take the 542 following values: 543 544 545 +-------+----------------------+ 546 | Value | Description | 547 +-------+----------------------+ 548 | 0x00 | octetArray | 549 | 0x01 | unsigned8 | 550 | 0x02 | unsigned16 | 551 | 0x03 | unsigned32 | 552 | 0x04 | unsigned64 | 553 | 0x05 | signed8 | 554 | 0x06 | signed16 | 555 | 0x07 | signed32 | 556 | 0x08 | signed64 | 557 | 0x09 | float32 | 558 | 0x0A | float64 | 559 | 0x0B | boolean | 560 | 0x0C | macAddress | 561 | 0x0D | string | 562 | 0x0E | dateTimeSeconds | 563 | 0x0F | dateTimeMilliseconds | 564 | 0x10 | dateTimeMicroseconds | 565 | 0x11 | dateTimeNanoseconds | 566 | 0x12 | ipv4Address | 567 | 0x13 | ipv6Address | 568 +-------+----------------------+ 569 570 571 572 575 576 577 A private enterprise number used to scope an information element ID, 578 as would appear in an IPFIX Template Record. This element can be used 579 to scope properties to a specific information element within a 580 Template. If the Enterprise ID bit of the corresponding Information 581 Element is cleared (has the value 0), this IE should be set to 0. The 582 presence of a non-zero value in this IE implies that the Enterprise ID 583 bit of the corresponding Information Element is set (has the value 1). 584 585 586 587 589 Authors' Addresses 591 Elisa Boschi 592 Hitachi Europe SAS 593 Immeuble Le Theleme 594 1503 Route les Dolines 595 06560 Valbonne 596 France 598 Phone: +33 4 89874100 599 Email: elisa.boschi@hitachi-eu.com 601 Brian H. Trammell 602 CERT Network Situational Awareness 603 Software Engineering Institute 604 4500 Fifth Avenue 605 Pittsburgh, Pennsylvania 15213 606 United States 608 Phone: +1 412 268 9748 609 Email: bht@cert.org 610 Lutz Mark 611 Fraunhofer Institute for Open Communication Systems 612 Kaiserin-Augusta-Allee 31 613 10589 Berlin 614 Germany 616 Phone: +49 30 3463 7306 617 Email: lutz.mark@fokus.fraunhofer.de 619 Tanja Zseby 620 Fraunhofer Institute for Open Communication Systems 621 Kaiserin-Augusta-Allee 31 622 10589 Berlin 623 Germany 625 Phone: +49 30 3463 7153 626 Email: tanja.zseby@fokus.fraunhofer.de 628 Full Copyright Statement 630 Copyright (C) The IETF Trust (2007). 632 This document is subject to the rights, licenses and restrictions 633 contained in BCP 78, and except as set forth therein, the authors 634 retain all their rights. 636 This document and the information contained herein are provided on an 637 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 638 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 639 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 640 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 641 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 642 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 644 Intellectual Property 646 The IETF takes no position regarding the validity or scope of any 647 Intellectual Property Rights or other rights that might be claimed to 648 pertain to the implementation or use of the technology described in 649 this document or the extent to which any license under such rights 650 might or might not be available; nor does it represent that it has 651 made any independent effort to identify any such rights. Information 652 on the procedures with respect to rights in RFC documents can be 653 found in BCP 78 and BCP 79. 655 Copies of IPR disclosures made to the IETF Secretariat and any 656 assurances of licenses to be made available, or the result of an 657 attempt made to obtain a general license or permission for the use of 658 such proprietary rights by implementers or users of this 659 specification can be obtained from the IETF on-line IPR repository at 660 http://www.ietf.org/ipr. 662 The IETF invites any interested party to bring to its attention any 663 copyrights, patents or patent applications, or other proprietary 664 rights that may cover technology that may be required to implement 665 this standard. Please address the information to the IETF at 666 ietf-ipr@ietf.org. 668 Acknowledgment 670 Funding for the RFC Editor function is provided by the IETF 671 Administrative Support Activity (IASA).