idnits 2.17.1 draft-aitken-ipfix-unobserved-fields-03.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 (4 July 2014) is 3577 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group P. Aitken 3 Internet-Draft Cisco Systems, Inc. 4 Intended Status: Standards Track 4 July 2014 5 Expires: July, 2015 7 Reporting Unobserved Fields in IPFIX 8 draft-aitken-ipfix-unobserved-fields-03 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire in July 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 The IPFIX protocol is designed to export information about 49 observations, and lacks a method for reporting that observations 50 are unavailable. This document discusses several methods for 51 reporting when fields are unavailable, reviews the advantages 52 and disadvantage of each, and recommends methods which should be 53 used. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 59 "OPTIONAL" in this document are to be interpreted as described 60 in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction ............................................ 3 65 2. Terminology ............................................. 4 66 2.1 New Terminology ........................................ 4 67 3. Potential Methods ....................................... 4 68 3.1 Zero-valued counters ................................... 4 69 3.2 Multiple Templates ..................................... 5 70 3.3 CommonProperties ....................................... 6 71 3.4 Default Values ......................................... 7 72 3.4.1 Default of Zero ...................................... 7 73 3.4.2 Default of all-ones ................................. 7 74 3.4.3 General default value ............................... 8 75 3.4.4 Field-specific default values........................ 8 76 3.5 "observedFieldsIndicator" bitfield ..................... 9 77 3.6 Length of Zero ......................................... 10 78 3.7 Size field ............................................. 10 79 3.8 Structure data lists ................................... 11 80 3.8.1 Status list ......................................... 11 81 3.8.2 Observed field list ................................. 11 82 3.8.3 Combined field and status list ...................... 12 83 4. Conclusion .............................................. 12 84 5. New Information Elements ................................ 13 85 6. Security Considerations ................................. 13 86 7. IANA Considerations ..................................... 13 87 8. References .............................................. 14 88 8.1 Normative References ................................... 14 89 8.2 Informative References ................................. 14 90 9. Acknowledgements ........................................ 14 91 10. Author's Address ....................................... 14 92 TODO: would it be useful to define two new fields for reporting 93 the start and end time of a period during which no observations 94 were made? 96 TODO: how do these methods work with structured data and MIBs? 98 1. Introduction 100 The IPFIX information model [RFC7012] contains a wide variety of 101 fields [IANA-IPFIX], which are not always present in all 102 traffic. For example, ICMP type and code. Indeed, some fields 103 are mutually exclusive. For example, IPv4 / IPv6 address fields; 104 UDP / TCP port numbers. 106 When an IPFIX Metering Process monitors a field, it only reports 107 whenever appropriate traffic is seen. ie, whenever the Observed 108 Traffic Stream [RFC5476] contains the field to be metered. No 109 output is generated whenever the monitored field is not present. 111 The IPFIX protocol lacks a method for the Metering Process to 112 actively express that although certain fields were being 113 monitored, no relevant observations were made, that a particular 114 field is not applicable, or that a value could not be calculated 115 for a derived field. Therefore the Collecting Process cannot 116 know whether the Metering Process was actively monitoring the 117 field, and can only infer from the lack of export that no 118 relevant observations were made. 120 Further, when a Metering Process monitors a combination of 121 fields, some may be present while others are not. Therefore the 122 Metering Process may observe values for some fields, though not 123 for others. 125 The IPFIX Protocol [RFC7011] requires the Exporting Process to 126 employ a number of templates in order to export these 127 combinations, using one template for each observed combination 128 of fields. Since the number of templates required grows 129 exponentially with the number of field combinations, the 130 templates can quickly become unmanageable. Indeed, just a few 131 sets of mutually exclusive fields are sufficient to exhaust the 132 template number space. 134 Clearly the IPFIX protocol [RFC7011] requires a method for the 135 Metering Process to actively express that although fields were 136 being monitored, no relevant observations were made. 138 Note that there are several cases where an observation may not 139 be available for a given field: 141 1. Unavailable / Not applicable: 143 The monitored field was not present in, or not applicable 144 to, the observed traffic. 145 eg, when RTP SSRC is requested for a TCP flow. 147 2. Not Calculated: 149 Although the required fields exist, something is preventing 150 the calculation from occurring. For example, not enough 151 data has been collected to calculate a TCP round-trip time. 153 This document discusses various potential methods for reporting 154 such unobserved fields, reviews the advantages and disadvantages 155 of each, and recommends suitable methods as an extension to the 156 IPFIX Protocol [RFC7011]. 158 2. Terminology 160 IPFIX-specific terminology used in this document is defined in 161 Section 2 of the IPFIX protocol specification [RFC7011]. As in 162 [RFC7011], these IPFIX-specific terms have the first letter of a 163 word capitalized when used in this document. 165 2.1 New Terminology 167 Unobserved Field 169 A field which a Metering Process is metering, but for which 170 no traffic has been seen or no data is available. 172 3. Potential Methods 174 This section discusses and evaluates various possible methods 175 for reporting Unobserved Fields. 177 3.1 Zero-valued counters 179 This method exports counters with a value of zero to indicate 180 that no traffic was observed. 182 For example, the following data records use zero-valued counters 183 to indicate that no traffic was observed from the specified 184 source or sent to the specified destination: 186 . sourceIPv4Address = n.n.n.n, packetTotalCount = 0 187 . destinationIPv4Prefix = n.n.n.n, packetTotalCount = 0 188 . bgpSourceAsNumber = nnnn, octetTotalCount = 0 189 . destinationTransportPort = pppp, octetTotalCount = 0 190 . protocolIdentifier = P, octetTotalCount = 0 192 Clearly this only works for specific addresses, address 193 prefixes, Autonomous systems, port numbers, protocols. The 194 method is not suitable for exhaustively reporting all addresses, 195 prefixes, Autonomous Systems, ports, or protocols from which no 196 traffic was sent or received. 198 Therefore, while this is a useful method, it addresses a 199 different problem. It does not meet the requirement of being 200 able to report unobserved fields and is therefore not a 201 solution. 203 3.2 Multiple Templates 205 The NetFlow v9 [RFC3954] and IPFIX [RFC7011] protocols are both 206 template based. Templates express which fields are present in 207 the exported Data Records. 209 When no value has been observed for a particular field, a new 210 template is generated without that corresponding Information 211 Element. Thus the Unobserved Field is simply omitted from the 212 export. ie, no values are exported for unobserved fields. 214 While this prevents an incorrect or misleading value from being 215 exported for the Unobserved Field, it may require a great many 216 Templates to be created. The number may soon become 217 unmanageable, or may exceed the Template number space - 218 especially when the Metering Process is metering a large number 219 of mutually-exclusive fields. 221 The IPFIX template number space is a little less than 16 bits 222 (256 through 65535 = 65280 templates), so the combinations of 16 223 different unobserved fields will exhaust the number space. 225 Eg, IPv4 and IPv6 traffic require separate templates, in order 226 to report either sourceIPv4Address and destinationIPv4Address, 227 or sourceIPv6Address and destinationIPv6Address. 229 Again, udpSourcePort and udpDestinationPort are mutually 230 exclusive with tcpSourcePort and tcpDestinationPort. Although 231 this may be mitigated by using the generic sourceTransportPort 232 and destinationTransportPort Information Elements together with 233 the protocolIdentifier, not all traffic is port based. Eg, these 234 port fields are mutually exclusive with icmpTypeCodeIPv4 and 235 icmpTypeCodeIPv6. 237 A final example is the MPLS label stack. Depending how many MPLS 238 labels are present in the Observed Traffic Stream, up to ten 239 different templates may be required, containing the ten MPLS 240 label stack Information Elements, mplsTopLabelStackSection 241 through mplsLabelStackSection10. 243 The main issue with this method is that since no data is 244 exported about unobserved fields, the Collecting Process cannot 245 tell whether the field was not being observed by the Metering 246 Process, or was being observed but no relevant traffic was seen. 248 Eg, if mplsLabelStackSection is not exported, the Collecting 249 Process is unable to determine whether MPLS traffic is being 250 actively monitored and no relevant traffic was seen, or MPLS 251 traffic is not being monitored. 253 Therefore this method does not meet the requirement of being 254 able to report unobserved fields and is therefore not a 255 solution. 257 3.3 CommonProperties 259 Common Properties divides Data Records into a core part in which 260 the fields are always observed, and additional parts according 261 to which other fields are observed. These are exported using the 262 method described in [RFC5473]. 264 One template is required to express which fields are present in 265 the core, and one Template is required for each combination of 266 additional fields. Since multiple templates are required, the 267 number of Templates may soon become unmanageable or may exceed 268 the Template number space as discussed in section 3.2 above. 270 Although Common Properties [RFC5473] isn't specified for 271 NetFlow v9 [RFC3954], there is no technical reason preventing 272 this. 274 The main issue with this method is that again, like the Multiple 275 Templates case above, no data is exported about Unobserved 276 Fields - so the Collecting Process cannot tell whether the field 277 was not being observed, or was being observed but no relevant 278 traffic was seen. 280 Therefore this method does not meet the requirement of being 281 able to report unobserved fields. 283 3.4 Default Values 285 With this method, a single Template specifies all the fields 286 which the Metering Process was asked to observe, regardless of 287 whether values were observed and are available for each of the 288 fields. Fields for which no value was observed, or for which the 289 value is unavailable, are exported with a default value. The 290 default value can be of several kinds as discussed below. 292 Note that multiple default values are required if it's necessary 293 to distinguish between the "not applicable" and "not required" 294 cases. In general, both cases may be represented by a single 295 value. 297 Since only one template is used, this scheme is trivial to 298 implement and works for both NetFlow v9 [RFC3954] and IPFIX. 300 Specific default values are discussed in the following sections. 302 3.4.1 Default of Zero 304 All unobserved fields are exported with the value zero. This has 305 the advantage that neither the Exporting Process nor the 306 Collecting Process needs any extra knowledge about the field. 308 However, if zero is a valid value for the field, it will be 309 impossible to distinguish an unobserved field from a real 310 observation. Eg, when reporting the number of lost packets, 311 packetsLost = 0 seems to indicate that no traffic was lost, when 312 it may be intended to indicate that there is no relevant 313 information to report. Even IP addresses of 0.0.0.0 and 0::0 are 314 valid representations. And zero is a valid value for 315 icmpTypeCodeIPv4 (indicating echo reply). 317 Therefore, although this method reports unobserved fields, it's 318 not always possible to determine whether or not the field was 319 observed. Therefore this method is not a suitable solution. 321 3.4.2 Default of all-ones 323 The "Default of all-ones" method is similar to the "Default of 324 Zero" method discussed above, except that the all-ones value 325 (0xFF, 0xFFFF, 0xFFFFFFFF, etc) is used for each Unobserved 326 Field. 328 Such values are often, though not always, reserved and therefore 329 may more clearly indicate whether or not the field was observed. 331 However, this method has the additional disadvantage that the 332 default value for Unobserved Fields changes with the size of the 333 field. Eg, 255 for 8-bit fields, 65535 for 16-bit fields, etc. 335 Additionally, field sorting is impacted without additional logic 336 to recognise the "all-ones" value, since "unobserved" appears as 337 the topmost value. 339 For this reason, and because these values are not always 340 reserved, this method is not a suitable solution. 342 3.4.3 General default value 344 This method is similar to the "Default of Zero" and "Default of 345 all-ones" methods discussed above, except that another non-zero, 346 non-0xFF...FF default value is used for each Unobserved Field. 347 Eg, a repeating pattern of ASCII space (0x20), or a hex number 348 such as "0xD15AB1ED". 350 However, it seems impossible to choose a value which would never 351 appear in a real observation, both for existing Information 352 Elements and for new Information Elements defined in future. 354 Eg, although "0XD15AB1EDD15AB1ED" may be quite unlikely, that's 355 not enough to give a robust indication. Further, "0XD15A" is 356 possible (eg, port 53594) and "0xD1" has a 1-in-256 chance of 357 incorrectly indicating that a one-octet field was unobserved. 359 Therefore this method is not a suitable solution. 361 3.4.4 Field-specific default values 363 Each field is provided with a special "unobserved" value, which 364 is outside the normal range of observed values. This value may 365 vary from field to field. 367 When no value is observed for the field, it's exported with the 368 "unobserved" value. 370 Eg, to report that the flow direction is not relevant to the 371 current flow, the flowDirection Information Element could be 372 exported with any value other than 0 (ingress) or 1 (egress). 374 Similarly, to report that the IP version is not relevant to the 375 current flow, the ipVersion Information Element could be 376 exported with a value between 10 and 15 (see [IANA-VERSION]). 378 Since the "unobserved" value is outwith the normal range of 379 values for the field, it is possible to distinguish an 380 unobserved field from a real observation. 382 However, both the Exporting Process and the Collecting Process 383 need extra knowledge about each individual field. 385 Further, not all Information Elements have a suitable value. Eg, 386 counter, time, and process ID Information Elements may use their 387 entire range of bits. 389 Therefore this method suffers from the same problem as the other 390 "Default Value" methods above, and is not a suitable solution. 392 3.5 "observedFieldsIndicator" bitfield 394 With this method, a single template contains Information 395 Elements for all the fields which the Metering Process was asked 396 to observe. 398 Additionally, the Template contains an "observedFieldsIndicator" 399 bitfield similar to the "flowKeyIndicator" (see [IANA-IPFIX] 400 173), in that each bit corresponds to one Information Element 401 in the flow record. Each bit in this field indicates whether or 402 not a value was observed for the corresponding Information 403 Element within the Data Record. 405 For each Data Record, the Collecting Process examines the 406 "observedFieldsIndicator" bitfield to discover which fields were 407 observed and which were unobserved within that Data Record. 408 Unobserved fields may therefore be exported with any value, 409 since they will be disregarded. 411 Since it uses only one template, this scheme is trivial to 412 implement and works for both NetFlow v9 [RFC3954] and IPFIX. 414 However, mediators MUST understand the "observedFieldsIndicator" 415 bitfield and correctly interpret it. eg, if the mediator is 416 aggregating Data Records, it MUST pay attention to the bitfield 417 in order to disregard data for unobserved fields. Additionally, 418 if fields are added to or removed from the Flow Record, bits in 419 the bitfield must be shifted accordingly. Therefore this 420 requires changes to IPFIX record processing. 422 Note that if the "observedFieldsIndicator" bitfield is sent in 423 an IPFIX Options Record, it expresses which fields are valid in 424 that Options Data Record. It's not possible to use option 425 scoping to report the "observedFieldsIndicator" bitfield for any 426 other Record. 428 Although this method clearly reports unobserved fields, it's 429 limited to a simple binary indication of whether or not a value 430 was observed. It's not possible to give a reason, or to 431 distinguish "Unavailable", "Not applicable" and "not calculated" 432 as discussed in section 1. 434 Provided that the simple boolean indication is sufficient, this 435 method provides a good solution. 437 This method requires a new "observedFieldsIndicator" Information 438 Element, as specified in section 5, "New Information Elements". 440 3.6 Length of Zero 442 This method exports a single Template containing Information 443 Elements for all the fields which the Metering Process was asked 444 to observe. Fields for which no value was observed are exported 445 using IPFIX variable-length encoding [RFC7011], with a length of 446 zero. Therefore unobserved fields are actively indicated. 448 Fields which may be unobserved must be anticipated ahead of time 449 and specified in the Template using IPFIX variable-length 450 encoding [RFC7011]. 452 While this method only requires a single Template, it doesn't 453 work for NetFlow v9 export [RFC3954] since NetFlow v9 doesn't 454 support variable-length encoding. 456 It also does not address the not-applicable versus 457 not-calculated case discussed in section 3.5, which may be 458 needed for some fields. 460 However, provided that the simple boolean indication is 461 sufficient, and especially when variable-length encoding is 462 already being used for the field, this method provides a good 463 solution. 465 3.7 Size field 467 With this method, a single Template contains Information 468 Elements for all the fields which the Metering Process was asked 469 to observe. 471 In addition, a "size" or "count" field is added to the Template, 472 indicating how many of the fields are valid. 474 Eg, the Template contains mplsTopLabelStackSection, 475 mplsLabelStackSection2, ..., mplsLabelStackSection10. 477 Additionally, mplsLabelStackDepth is provided, indicating how 478 many of the MPLS label elements are valid. 480 Clearly this method is field-specific. Instead, the solution 481 should use a structured data list as discussed in section 3.8 482 below. Therefore this method is not recommended. 484 3.8 Structure data lists 486 With this method, a single template contains Information 487 Elements for all the fields which the Metering Process was asked 488 to observe. A list is appended to each Data Record to provide 489 more information about the fields in the Template. 491 Several types of list are possible as described below. 493 3.8.1 Status list 495 A new Information Element defines the status of each field. Eg, 496 observed, unavailable, not applicable, not calculated. One 497 status is provided per Information Element. 499 A status list is encoded using a basicList as described in 500 [RFC6313], and the list is appended to the Data Record. 502 This method is similar to the "observedFieldsIndicator" bitfield 503 discussed in section 3.5, with the advantage that more 504 information is available about each field. 506 However, this method suffers from the same mediator issue. ie, 507 the list must be understood by mediators, and must be modified 508 when a mediator adds fields to, or removes fields from, the Data 509 Record. 511 With one octet per status, the Data Record is not overly 512 burdened. 514 While this method offers some advantage over the 515 "observedFieldsIndicator" bitfield discussed in section 3.5, it 516 is not recommended. 518 3.8.2 Observed field list 520 A list of informationElementIndex, indicating which of the 521 elements in the Template contains valid values, is appended to 522 each Data Record. 524 Elements which appear in the Template but not in the list were 525 not observed, not applicable, or could not be calculated. 527 Since informationElementIndex is 16 bits long, this method 528 produces a list which is twice as long as that in section 3.8.1 529 above. 531 Since the order of the fields in the list is unimportant, when a 532 mediator adds fields to the Data Record, the list can simply be 533 extended. Therefore the mediator issue is mitigated to some 534 extent. 536 However, it's not possible to tell why a particular Information 537 Element is not available. 539 Since the "Combined" method discussed in section 3.8.3 below 540 offers a better solution, this method is not recommended. 542 3.8.3 Combined field and status list 544 This method combines the status and field list from sections 545 3.8.1 and 3.8.2, by exporting a subTemplateList containing 546 {informationElementIndex, status} pairs. 548 Therefore this method produces a list which is thrice as long as 549 that in section 3.8.1 above. Additionally, a further template is 550 required to encode the {informationElementIndex, status} pair. 552 The status makes it possible for the Collecting Process to 553 understand why a particular Information Element is not 554 available. 556 Since the order of the fields in the list is unimportant, when a 557 mediator adds fields to the Data Record, the list can simply be 558 extended. Therefore the mediator issue is mitigated to some 559 extent. 561 This method is the most flexible and informative of all the 562 structured data solutions. However, it incurs a penalty of an 563 additional template to export the subTemplateList. Therefore 564 this method is not recommended. 566 Not-TODO: could be implemented as two parallel basicLists, or a 567 basicList of a new "Element+Status" IE. 569 4. Conclusion 571 Several methods of encoding "unobserved" fields have been 572 presented. Each has pros and cons. 574 The only methods which satisfactorily meet the requirements are 575 the "observedFieldsIndicator" bitfield in section 3.5, and the 576 "Length of Zero" method in section 3.6. 578 These methods may be combined in order to report when no value 579 is available for a given export field. 581 In the general case, the "observedFieldsIndicator" bitfield 582 method specified in section 3.5 should be used. 584 However, when IPFIX variable-length encoding can be used, or is 585 already being used, the "Length of Zero" method specified in 586 section 3.6 may be used. 588 Therefore this document specifies an extension to the IPFIX 589 protocol [RFC7011], such that a variable-length encoding with a 590 length of zero indicates that no value was available for the 591 corresponding Information Element. 593 The ability to indicate Unobserved Fields conveys an additional 594 benefit: the ability for the Metering Process to indicate that 595 it has begun to monitor a new flow, but does not yet have 596 anything to export. Therefore, all the fields are unobserved. 598 5. New Information Elements 600 This document defines the following new IPFIX Information 601 Elements: 603 observedFieldsIndicator 605 Description: 606 This bit field indicates which of the Information Elements 607 within a Data Record have been observed. Each bit of the 608 observedFieldsIndicator represents an Information Element 609 in the Data Record with the n-th bit representing the n-th 610 Information Element. 611 A bit set to value 1 indicates that the corresponding 612 Information Element was observed and contains a valid 613 value. A bit set to value 0 indicates that the 614 corresponding Information Element was not observed and 615 contains an invalid value. The Information Element value 616 SHOULD be set to zero, and MUST be disregarded by the 617 Collecting Process. 618 Information Elements which have no observedFieldsIndicator 619 bit MUST contain a valid value. 620 If the Data Record contains more than 64 Information 621 Elements, the corresponding Template SHOULD be designed 622 such that all unobserved fields are among the first 64 623 Information Elements, because the observedFieldsIndicator 624 only contains 64 bits. If the Data Record contains less 625 than 64 Information Elements, then the bits in the 626 observedFieldsIndicator for which no corresponding 627 Information Element exists MUST have the value 0. 629 Abstract Data Type: unsigned64 630 Data Type Semantics: flags 631 ElementId: TBD1 633 6. Security Considerations 635 No additional security considerations are introduced in this 636 document. The same security considerations as for the IPFIX 637 protocol [RFC7011] apply. 639 7. IANA Considerations 641 Additional Information Elements to be allocated in the 642 [IANA-IPFIX] registry per section 5, "New Information Elements." 644 8. References 646 8.1 Normative References 648 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 649 "Specification of the 650 IP Flow Information Export (IPFIX) Protocol 651 for the Exchange of Flow Information", 652 STD 77, RFC 7011, September 2013. 654 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 655 Requirement Levels, BCP 14, RFC 2119, March 1997 657 8.2 Informative References 659 [RFC7012] Claise, B., Ed., and B. Trammell, Ed., 660 "Information Model for 661 IP Flow Information Export (IPFIX)", 662 RFC 7012, September 2013. 664 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 665 Redundancy in IP Flow Information Export (IPFIX) and 666 Packet Sampling (PSAMP) Reports", 667 RFC 5473, March 2009. 669 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 670 Protocol Specifications", RFC 5476, March 2009. 672 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 673 Export Version 9", RFC 3954, October 2004. 675 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 676 "Export of Structured Data in IP Flow Information 677 Export (IPFIX)", RFC 6313, July 2011. 679 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xml 681 [IANA-VERSION] 682 http://www.iana.org/assignments/version-numbers/ver 683 sion-numbers.xml 685 9. Acknowledgements 687 Thanks to Aamer Akhter and Luca Deri for initial review and 688 feedback, to Andrew Johnson for the lists method, and to Jan 689 Novak, Andrew Johnson, Colin McDowall, and Dana Blair for 690 reviewing the draft and providing feedback. 692 10. Author's Address 694 Paul Aitken 695 Cisco Systems, Inc. 696 96 Commercial Quay 697 Commercial Street 698 Edinburgh, EH6 6LX, United Kingdom 700 Phone: +44 131 561 3616 701 Email: paitken@cisco.com