idnits 2.17.1 draft-aitken-ipfix-unobserved-fields-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 14) being 69 lines 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 (31 Dec 2013) is 3762 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 (~~), 2 warnings (==), 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 31 Dec 2013 5 Expires: July, 2014 7 Reporting Unobserved Fields in IPFIX 8 draft-aitken-ipfix-unobserved-fields-02 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) 2013 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 93 TODO: would it be useful to define two new fields for reporting 94 the start and end time of a period during which no observations 95 were made? 97 TODO: how do these methods work with structured data and MIBs? 99 1. Introduction 101 The IPFIX information model [RFC7012] contains a wide variety of 102 fields [IANA-IPFIX], which are not always present in all 103 traffic. For example, ICMP type and code. Indeed, some fields 104 are mutually exclusive. For example, IPv4 / IPv6 address fields; 105 UDP / TCP port numbers. 107 When an IPFIX Metering Process monitors a field, it only reports 108 whenever appropriate traffic is seen. ie, whenever the Observed 109 Traffic Stream [RFC5476] contains the field to be metered. No 110 output is generated whenever the monitored field is not present. 112 The IPFIX protocol lacks a method for the Metering Process to 113 actively express that although certain fields were being 114 monitored, no relevant observations were made, that a particular 115 field is not applicable, or that a value could not be calculated 116 for a derived field. Therefore the Collecting Process cannot 117 know whether the Metering Process was actively monitoring the 118 field, and can only infer from the lack of export that no 119 relevant observations were made. 121 Further, when a Metering Process monitors a combination of 122 fields, some may be present while others are not. Therefore the 123 Metering Process may observe values for some fields, though not 124 for others. 126 The IPFIX Protocol [RFC7011] requires the Exporting Process to 127 employ a number of templates in order to export these 128 combinations, using one template for each observed combination 129 of fields. Since the number of templates required grows 130 exponentially with the number of field combinations, the 131 templates can quickly become unmanageable. Indeed, just a few 132 sets of mutually exclusive fields are sufficient to exhaust the 133 template number space. 135 Clearly the IPFIX protocol [RFC7011] requires a method for the 136 Metering Process to actively express that although fields were 137 being monitored, no relevant observations were made. 139 Note that there are several cases where an observation may not 140 be available for a given field: 142 1. Unavailable / Not applicable: 144 The monitored field was not present in, or not applicable 145 to, the observed traffic. 146 eg, when RTP SSRC is requested for a TCP flow. 148 2. Not Calculated: 150 Although the required fields exist, something is preventing 151 the calculation from occurring. For example, not enough 152 data has been collected to calculate a TCP round-trip time. 154 This document discusses various potential methods for reporting 155 such unobserved fields, reviews the advantages and disadvantages 156 of each, and recommends suitable methods as an extension to the 157 IPFIX Protocol [RFC7011]. 159 2. Terminology 161 IPFIX-specific terminology used in this document is defined in 162 Section 2 of the IPFIX protocol specification [RFC7011]. As in 163 [RFC7011], these IPFIX-specific terms have the first letter of a 164 word capitalized when used in this document. 166 2.1 New Terminology 168 Unobserved Field 170 A field which a Metering Process is metering, but for which 171 no traffic has been seen or no data is available. 173 3. Potential Methods 175 This section discusses and evaluates various possible methods 176 for reporting Unobserved Fields. 178 3.1 Zero-valued counters 180 This method exports counters with a value of zero to indicate 181 that no traffic was observed. 183 For example, the following data records use zero-valued counters 184 to indicate that no traffic was observed from the specified 185 source or sent to the specified destination: 187 . sourceIPv4Address = n.n.n.n, packetTotalCount = 0 188 . destinationIPv4Prefix = n.n.n.n, packetTotalCount = 0 189 . bgpSourceAsNumber = nnnn, octetTotalCount = 0 190 . destinationTransportPort = pppp, octetTotalCount = 0 191 . protocolIdentifier = P, octetTotalCount = 0 193 Clearly this only works for specific addresses, address 194 prefixes, Autonomous systems, port numbers, protocols. The 195 method is not suitable for exhaustively reporting all addresses, 196 prefixes, Autonomous Systems, ports, or protocols from which no 197 traffic was sent or received. 199 Therefore, while this is a useful method, it addresses a 200 different problem. It does not meet the requirement of being 201 able to report unobserved fields and is therefore not a 202 solution. 204 3.2 Multiple Templates 206 The NetFlow v9 [RFC3954] and IPFIX [RFC7011] protocols are both 207 template based. Templates express which fields are present in 208 the exported Data Records. 210 When no value has been observed for a particular field, a new 211 template is generated without that corresponding Information 212 Element. Thus the Unobserved Field is simply omitted from the 213 export. ie, no values are exported for unobserved fields. 215 While this prevents an incorrect or misleading value from being 216 exported for the Unobserved Field, it may require a great many 217 Templates to be created. The number may soon become 218 unmanageable, or may exceed the Template number space - 219 especially when the Metering Process is metering a large number 220 of mutually-exclusive fields. 222 The IPFIX template number space is a little less than 16 bits 223 (256 through 65535 = 65280 templates), so the combinations of 16 224 different unobserved fields will exhaust the number space. 226 Eg, IPv4 and IPv6 traffic require separate templates, in order 227 to report either sourceIPv4Address and destinationIPv4Address, 228 or sourceIPv6Address and destinationIPv6Address. 230 Again, udpSourcePort and udpDestinationPort are mutually 231 exclusive with tcpSourcePort and tcpDestinationPort. Although 232 this may be mitigated by using the generic sourceTransportPort 233 and destinationTransportPort Information Elements together with 234 the protocolIdentifier, not all traffic is port based. Eg, these 235 port fields are mutually exclusive with icmpTypeCodeIPv4 and 236 icmpTypeCodeIPv6. 238 A final example is the MPLS label stack. Depending how many MPLS 239 labels are present in the Observed Traffic Stream, up to ten 240 different templates may be required, containing the ten MPLS 241 label stack Information Elements, mplsTopLabelStackSection 242 through mplsLabelStackSection10. 244 The main issue with this method is that since no data is 245 exported about unobserved fields, the Collecting Process cannot 246 tell whether the field was not being observed by the Metering 247 Process, or was being observed but no relevant traffic was seen. 249 Eg, if mplsLabelStackSection is not exported, the Collecting 250 Process is unable to determine whether MPLS traffic is being 251 actively monitored and no relevant traffic was seen, or MPLS 252 traffic is not being monitored. 254 Therefore this method does not meet the requirement of being 255 able to report unobserved fields and is therefore not a 256 solution. 258 3.3 CommonProperties 260 Common Properties divides Data Records into a core part in which 261 the fields are always observed, and additional parts according 262 to which other fields are observed. These are exported using the 263 method described in [RFC5473]. 265 One template is required to express which fields are present in 266 the core, and one Template is required for each combination of 267 additional fields. Since multiple templates are required, the 268 number of Templates may soon become unmanageable or may exceed 269 the Template number space as discussed in section 3.2 above. 271 Although Common Properties [RFC5473] isn't specified for 272 NetFlow v9 [RFC3954], there is no technical reason preventing 273 this. 275 The main issue with this method is that again, like the Multiple 276 Templates case above, no data is exported about Unobserved 277 Fields - so the Collecting Process cannot tell whether the field 278 was not being observed, or was being observed but no relevant 279 traffic was seen. 281 Therefore this method does not meet the requirement of being 282 able to report unobserved fields. 284 3.4 Default Values 286 With this method, a single Template specifies all the fields 287 which the Metering Process was asked to observe, regardless of 288 whether values were observed and are available for each of the 289 fields. Fields for which no value was observed, or for which the 290 value is unavailable, are exported with a default value. The 291 default value can be of several kinds as discussed below. 293 Note that multiple default values are required if it's necessary 294 to distinguish between the "not applicable" and "not required" 295 cases. In general, both cases may be represented by a single 296 value. 298 Since only one template is used, this scheme is trivial to 299 implement and works for both NetFlow v9 [RFC3954] and IPFIX. 301 Specific default values are discussed in the following sections. 303 3.4.1 Default of Zero 305 All unobserved fields are exported with the value zero. This has 306 the advantage that neither the Exporting Process nor the 307 Collecting Process needs any extra knowledge about the field. 309 However, if zero is a valid value for the field, it will be 310 impossible to distinguish an unobserved field from a real 311 observation. Eg, when reporting the number of lost packets, 312 packetsLost = 0 seems to indicate that no traffic was lost, when 313 it may be intended to indicate that there is no relevant 314 information to report. Even IP addresses of 0.0.0.0 and 0::0 are 315 valid representations. And zero is a valid value for 316 icmpTypeCodeIPv4 (indicating echo reply). 318 Therefore, although this method reports unobserved fields, it's 319 not always possible to determine whether or not the field was 320 observed. Therefore this method is not a suitable solution. 322 3.4.2 Default of all-ones 324 The "Default of all-ones" method is similar to the "Default of 325 Zero" method discussed above, except that the all-ones value 326 (0xFF, 0xFFFF, 0xFFFFFFFF, etc) is used for each Unobserved 327 Field. 329 Such values are often, though not always, reserved and therefore 330 may more clearly indicate whether or not the field was observed. 332 However, this method has the additional disadvantage that the 333 default value for Unobserved Fields changes with the size of the 334 field. Eg, 255 for 8-bit fields, 65535 for 16-bit fields, etc. 336 Additionally, field sorting is impacted without additional logic 337 to recognise the "all-ones" value, since "unobserved" appears as 338 the topmost value. 340 For this reason, and because these values are not always 341 reserved, this method is not a suitable solution. 343 3.4.3 General default value 345 This method is similar to the "Default of Zero" and "Default of 346 all-ones" methods discussed above, except that another non-zero, 347 non-0xFF...FF default value is used for each Unobserved Field. 348 Eg, a repeating pattern of ASCII space (0x20), or a hex number 349 such as "0xD15AB1ED". 351 However, it seems impossible to choose a value which would never 352 appear in a real observation, both for existing Information 353 Elements and for new Information Elements defined in future. 355 Eg, although "0XD15AB1EDD15AB1ED" may be quite unlikely, that's 356 not enough to give a robust indication. Further, "0XD15A" is 357 possible (eg, port 53594) and "0xD1" has a 1-in-256 chance of 358 incorrectly indicating that a one-octet field was unobserved. 360 Therefore this method is not a suitable solution. 362 3.4.4 Field-specific default values 364 Each field is provided with a special "unobserved" value, which 365 is outside the normal range of observed values. This value may 366 vary from field to field. 368 When no value is observed for the field, it's exported with the 369 "unobserved" value. 371 Eg, to report that the flow direction is not relevant to the 372 current flow, the flowDirection Information Element could be 373 exported with any value other than 0 (ingress) or 1 (egress). 375 Similarly, to report that the IP version is not relevant to the 376 current flow, the ipVersion Information Element could be 377 exported with a value between 10 and 15 (see [IANA-VERSION]). 379 Since the "unobserved" value is outwith the normal range of 380 values for the field, it is possible to distinguish an 381 unobserved field from a real observation. 383 However, both the Exporting Process and the Collecting Process 384 need extra knowledge about each individual field. 386 Further, not all Information Elements have a suitable value. Eg, 387 counter, time, and process ID Information Elements may use their 388 entire range of bits. 390 Therefore this method suffers from the same problem as the other 391 "Default Value" methods above, and is not a suitable solution. 393 3.5 "observedFieldsIndicator" bitfield 395 With this method, a single template contains Information 396 Elements for all the fields which the Metering Process was asked 397 to observe. 399 Additionally, the Template contains an "observedFieldsIndicator" 400 bitfield similar to the "flowKeyIndicator" (see [IANA-IPFIX] 401 173), in that each bit corresponds to one Information Element 402 in the flow record. Each bit in this field indicates whether or 403 not a value was observed for the corresponding Information 404 Element within the Data Record. 406 For each Data Record, the Collecting Process examines the 407 "observedFieldsIndicator" bitfield to discover which fields were 408 observed and which were unobserved within that Data Record. 409 Unobserved fields may therefore be exported with any value, 410 since they will be disregarded. 412 Since it uses only one template, this scheme is trivial to 413 implement and works for both NetFlow v9 [RFC3954] and IPFIX. 415 However, mediators MUST understand the "observedFieldsIndicator" 416 bitfield and correctly interpret it. eg, if the mediator is 417 aggregating Data Records, it MUST pay attention to the bitfield 418 in order to disregard data for unobserved fields. Additionally, 419 if fields are added to or removed from the Flow Record, bits in 420 the bitfield must be shifted accordingly. Therefore this 421 requires changes to IPFIX record processing. 423 Note that if the "observedFieldsIndicator" bitfield is sent in 424 an IPFIX Options Record, it expresses which fields are valid in 425 that Options Data Record. It's not possible to use option 426 scoping to report the "observedFieldsIndicator" bitfield for any 427 other Record. 429 Although this method clearly reports unobserved fields, it's 430 limited to a simple binary indication of whether or not a value 431 was observed. It's not possible to give a reason, or to 432 distinguish "Unavailable", "Not applicable" and "not calculated" 433 as discussed in section 1. 435 Provided that the simple boolean indication is sufficient, this 436 method provides a good solution. 438 This method requires a new "observedFieldsIndicator" Information 439 Element, as specified in section 5, "New Information Elements". 441 3.6 Length of Zero 443 This method exports a single Template containing Information 444 Elements for all the fields which the Metering Process was asked 445 to observe. Fields for which no value was observed are exported 446 using IPFIX variable-length encoding [RFC7011], with a length of 447 zero. Therefore unobserved fields are actively indicated. 449 Fields which may be unobserved must be anticipated ahead of time 450 and specified in the Template using IPFIX variable-length 451 encoding [RFC7011]. 453 While this method only requires a single Template, it doesn't 454 work for NetFlow v9 export [RFC3954] since NetFlow v9 doesn't 455 support variable-length encoding. 457 It also does not address the not-applicable versus 458 not-calculated case discussed in section 3.5, which may be 459 needed for some fields. 461 However, provided that the simple boolean indication is 462 sufficient, and especially when variable-length encoding is 463 already being used for the field, this method provides a good 464 solution. 466 3.7 Size field 468 With this method, a single Template contains Information 469 Elements for all the fields which the Metering Process was asked 470 to observe. 472 In addition, a "size" or "count" field is added to the Template, 473 indicating how many of the fields are valid. 475 Eg, the Template contains mplsTopLabelStackSection, 476 mplsLabelStackSection2, ..., mplsLabelStackSection10. 478 Additionally, mplsLabelStackDepth is provided, indicating how 479 many of the MPLS label elements are valid. 481 Clearly this method is field-specific. Instead, the solution 482 should use a structured data list as discussed in section 3.8 483 below. Therefore this method is not recommended. 485 3.8 Structure data lists 487 With this method, a single template contains Information 488 Elements for all the fields which the Metering Process was asked 489 to observe. A list is appended to each Data Record to provide 490 more information about the fields in the Template. 492 Several types of list are possible as described below. 494 3.8.1 Status list 496 A new Information Element defines the status of each field. Eg, 497 observed, unavailable, not applicable, not calculated. One 498 status is provided per Information Element. 500 A status list is encoded using a basicList as described in 501 [RFC6313], and the list is appended to the Data Record. 503 This method is similar to the "observedFieldsIndicator" bitfield 504 discussed in section 3.5, with the advantage that more 505 information is available about each field. 507 However, this method suffers from the same mediator issue. ie, 508 the list must be understood by mediators, and must be modified 509 when a mediator adds fields to, or removes fields from, the Data 510 Record. 512 With one octet per status, the Data Record is not overly 513 burdened. 515 While this method offers some advantage over the 516 "observedFieldsIndicator" bitfield discussed in section 3.5, it 517 is not recommended. 519 3.8.2 Observed field list 521 A list of informationElementIndex, indicating which of the 522 elements in the Template contains valid values, is appended to 523 each Data Record. 525 Elements which appear in the Template but not in the list were 526 not observed, not applicable, or could not be calculated. 528 Since informationElementIndex is 16 bits long, this method 529 produces a list which is twice as long as that in section 3.8.1 530 above. 532 Since the order of the fields in the list is unimportant, when a 533 mediator adds fields to the Data Record, the list can simply be 534 extended. Therefore the mediator issue is mitigated to some 535 extent. 537 However, it's not possible to tell why a particular Information 538 Element is not available. 540 Since the "Combined" method discussed in section 3.8.3 below 541 offers a better solution, this method is not recommended. 543 3.8.3 Combined field and status list 545 This method combines the status and field list from sections 546 3.8.1 and 3.8.2, by exporting a subTemplateList containing 547 {informationElementIndex, status} pairs. 549 Therefore this method produces a list which is thrice as long as 550 that in section 3.8.1 above. Additionally, a further template is 551 required to encode the {informationElementIndex, status} pair. 553 The status makes it possible for the Collecting Process to 554 understand why a particular Information Element is not 555 available. 557 Since the order of the fields in the list is unimportant, when a 558 mediator adds fields to the Data Record, the list can simply be 559 extended. Therefore the mediator issue is mitigated to some 560 extent. 562 This method is the most flexible and informative of all the 563 structured data solutions. However, it incurs a penalty of an 564 additional template to export the subTemplateList. Therefore 565 this method is not recommended. 567 Not-TODO: could be implemented as two parallel basicLists, or a 568 basicList of a new "Element+Status" IE. 570 4. Conclusion 572 Several methods of encoding "unobserved" fields have been 573 presented. Each has pros and cons. 575 The only methods which satisfactorily meet the requirements are 576 the "observedFieldsIndicator" bitfield in section 3.5, and the 577 "Length of Zero" method in section 3.6. 579 These methods may be combined in order to report when no value 580 is available for a given export field. 582 In the general case, the "observedFieldsIndicator" bitfield 583 method specified in section 3.5 should be used. 585 However, when IPFIX variable-length encoding can be used, or is 586 already being used, the "Length of Zero" method specified in 587 section 3.6 may be used. 589 Therefore this document specifies an extension to the IPFIX 590 protocol [RFC7011], such that a variable-length encoding with a 591 length of zero indicates that no value was available for the 592 corresponding Information Element. 594 The ability to indicate Unobserved Fields conveys an additional 595 benefit: the ability for the Metering Process to indicate that 596 it has begun to monitor a new flow, but does not yet have 597 anything to export. Therefore, all the fields are unobserved. 599 5. New Information Elements 601 This document defines the following new IPFIX Information 602 Elements: 604 observedFieldsIndicator 606 Description: 607 This bit field indicates which of the Information Elements 608 within a Data Record have been observed. Each bit of the 609 observedFieldsIndicator represents an Information Element 610 in the Data Record with the n-th bit representing the n-th 611 Information Element. 612 A bit set to value 1 indicates that the corresponding 613 Information Element was observed and contains a valid 614 value. A bit set to value 0 indicates that the 615 corresponding Information Element was not observed and 616 contains an invalid value. The Information Element value 617 SHOULD be set to zero, and MUST be disregarded by the 618 Collecting Process. 619 Information Elements which have no observedFieldsIndicator 620 bit MUST contain a valid value. 621 If the Data Record contains more than 64 Information 622 Elements, the corresponding Template SHOULD be designed 623 such that all unobserved fields are among the first 64 624 Information Elements, because the observedFieldsIndicator 625 only contains 64 bits. If the Data Record contains less 626 than 64 Information Elements, then the bits in the 627 observedFieldsIndicator for which no corresponding 628 Information Element exists MUST have the value 0. 630 Abstract Data Type: unsigned64 631 Data Type Semantics: flags 632 ElementId: TBD1 634 6. Security Considerations 636 No additional security considerations are introduced in this 637 document. The same security considerations as for the IPFIX 638 protocol [RFC7011] apply. 640 7. IANA Considerations 642 Additional Information Elements to be allocated in the 643 [IANA-IPFIX] registry per section 5, "New Information Elements." 645 8. References 647 8.1 Normative References 649 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 650 "Specification of the 651 IP Flow Information Export (IPFIX) Protocol 652 for the Exchange of Flow Information", 653 STD 77, RFC 7011, September 2013. 655 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 656 Requirement Levels, BCP 14, RFC 2119, March 1997 658 8.2 Informative References 660 [RFC7012] Claise, B., Ed., and B. Trammell, Ed., 661 "Information Model for 662 IP Flow Information Export (IPFIX)", 663 RFC 7012, September 2013. 665 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 666 Redundancy in IP Flow Information Export (IPFIX) and 667 Packet Sampling (PSAMP) Reports", 668 RFC 5473, March 2009. 670 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 671 Protocol Specifications", RFC 5476, March 2009. 673 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 674 Export Version 9", RFC 3954, October 2004. 676 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 677 "Export of Structured Data in IP Flow Information 678 Export (IPFIX)", RFC 6313, July 2011. 680 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xml 682 [IANA-VERSION] 683 http://www.iana.org/assignments/version-numbers/ver 684 sion-numbers.xml 686 9. Acknowledgements 688 Thanks to Aamer Akhter and Luca Deri for initial review and 689 feedback, to Andrew Johnson for the lists method, and to Jan 690 Novak, Andrew Johnson, Colin McDowall, and Dana Blair for 691 reviewing the draft and providing feedback. 693 10. Author's Address 695 Paul Aitken 696 Cisco Systems, Inc. 697 96 Commercial Quay 698 Commercial Street 699 Edinburgh, EH6 6LX, United Kingdom 701 Phone: +44 131 561 3616 702 Email: paitken@cisco.com