idnits 2.17.1 draft-ietf-ipfix-protocol-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-ietf-ipfix-protocol-3', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipfix-protocol-3', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ipfix-protocol-3', but the file name used is 'draft-ietf-ipfix-protocol-03' == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 260 has weird spacing: '...emplate manag...' == Line 460 has weird spacing: '...n could be co...' == Line 1977 has weird spacing: '...ormance issue...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'not RECOMMENDED' in this paragraph: PROTO-12: Do we need the IETF exclusive template flowset format? suggested solution: - reserve flowset ID 0 & 1 for compatibility with NFv9 - try to make flowset ID 2 & 3 definition fully compatible with NFv9 - add note that if you implement ID 2/3 correctly, you can also process ID 0/1. PROTO-13: How to distinguish IETF field IDs from vendor field IDs - Specify method for detecting the difference in section 8. - Add a note that there is a common ID space for for field types used in data templates and option templates - (Editorial) make clear that Section 8.2 also applies to option templates PROTO-14: Why do we need padding? Should we shift it to MAY? limit the size of the padding? Yes solution: - padding shorter than actual Record Length - fill with 0 - only at end of flowset - applies to all flowsets - padding is OPTIONAL (MAY) , not RECOMMENDED (SHOULD) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream does not have differing SID values. The Exporting Process MUST not transmit messages inside one stream with multiple SID values. The correlated Flow Records are then treated like a normal export Flow. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 2003) is 7743 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) == Missing Reference: 'IPFIX-PROTO' is mentioned on line 311, but not defined == Missing Reference: 'RFC1889' is mentioned on line 375, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Missing Reference: 'SCTP-PR' is mentioned on line 655, but not defined -- Looks like a reference, but probably isn't: '0' on line 1542 == Missing Reference: 'RFC2402' is mentioned on line 1903, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RFC2406' is mentioned on line 1904, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Unused Reference: 'IPFIX-EVAL' is defined on line 2248, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'IPFIX-ARCH' == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-02 == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-as-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ipfix-as (ref. 'IPFIX-AS') ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-16) exists of draft-ietf-ipfix-reqs-15 == Outdated reference: A later version (-03) exists of draft-leinen-ipfix-eval-contrib-02 == Outdated reference: A later version (-08) exists of draft-claise-netflow-9-07 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-02 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-11 Summary: 10 errors (**), 1 flaw (~~), 25 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX working group 3 Internet Draft EDITORS: B. Claise 4 draft-ietf-ipfix-protocol-3.txt Cisco Systems 5 Expires: July 2004 Mark Fullmer 6 OARnet 7 Paul Calato 8 Riverstone Networks 9 Reinaldo Penno 10 Nortel Networks 11 January 2003 13 IPFIX Protocol Specifications 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsolete by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://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 Abstract 35 This document specifies the IPFIX protocol that provides network 36 operators with access to IP flow information. In order to export 37 IP flow information to the IPFIX collecting process, a common method 38 of representing the flow data and a standard means of communicating 39 them from an exporter to a collector required. This document 40 describes how the IPFIX flow record data, options record data and 41 control information (templates for example) are carried over a 42 congestion-aware transport protocol from IPFIX exporting process to 43 IPFIX collecting process. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119. 51 Table of Contents 53 1. Points of Discussion.........................................3 54 1.1 Open Issues................................................3 55 1.2 Action Items...............................................7 56 2. Introduction.................................................7 57 2.1 IPFIX Documents Overview...................................7 58 3. Terminology..................................................8 59 3.1 Terminology Summary Table.................................13 60 4. Criteria for Flow Expiration and Export.....................14 61 4.1 Flow Expiration...........................................14 62 4.2 Flow Export...............................................14 63 5. Transport Protocol..........................................15 64 5.1 Transport Compliance and Transport Usage..................15 65 5.2 TCP.......................................................15 66 5.3 SCTP......................................................16 67 5.3.1 Congestion Avoidance.................................16 68 5.3.2 Reliability..........................................16 69 5.3.3 Exporting Process....................................16 70 5.3.3.1 MTU size............................................16 71 5.3.3.2 Source ID...........................................17 72 5.3.3.3 Association.........................................17 73 5.3.3.4 Stream..............................................17 74 5.3.3.5 Template............................................18 75 5.3.4 Collecting Process...................................18 76 5.3.5 SCTP Partially Reliable..............................19 77 5.4 UDP.......................................................19 78 6. Failover....................................................19 79 6.1 Simple Failover based on the transport protocol...........19 80 6.2 Something else?...........................................20 81 7. Message Layout..............................................20 82 8. IPFIX Message Format........................................21 83 8.1 Header Format.............................................21 84 8.2 Field Type Format.........................................22 85 8.3 Template FlowSet Format...................................24 86 8.3.1 IETF Exclusive Template FlowSet Format.................24 87 8.3.2 Vendor Specified Template FlowSet Format...............26 88 8.4 Data FlowSet Format.......................................27 89 8.5 Options Template FlowSet Format...........................29 90 8.5.1 IETF Exclusive Options Template FlowSet Format.........29 91 8.5.2 Vendor Specified Options Template FlowSet Format.......31 92 8.5.3 Options Data Record Format.............................32 93 9. Specific Reporting Requirements.............................34 94 9.1 The Metering Process Statistics Option Template...........35 95 10. Export Packet "Export Time" Computation and Flow Record Time35 96 10.1 Microsecond Precision....................................35 97 10.2 Millisecond Precision....................................36 98 10.3 Nanosecond Precision.....................................37 99 10.4 Multiple Precisions......................................37 100 11. Linkage with the Information Model.........................37 101 11.1 Boolean..................................................37 102 11.2 Byte.....................................................37 103 11.3 UnsignedByte.............................................38 104 11.4 Short....................................................38 105 11.5 Reduced Size Encoding of Integral Types..................38 106 12. Variable Length Data Type..................................39 107 13. Template Management........................................40 108 14. The Collecting Process's Side..............................41 109 15. Security Considerations....................................43 110 15.1 IPsec Usage..............................................43 111 15.1.1 Selectors............................................43 112 15.1.2 Mode.................................................44 113 15.1.3 Key Management.......................................44 114 15.1.4 Security Policy......................................44 115 15.1.5 Authentication.......................................44 116 15.1.6 Availability.........................................44 117 15.2 TLS Usage................................................45 118 15.3 Protection against DoS attacks...........................45 119 15.4 When IPsec or TLS is not an option.......................45 120 15.5 Logging an IPFIX Attack..................................46 121 16. IANA Considerations........................................46 122 17. Examples...................................................47 123 17.1 Message Header Example...................................47 124 17.2 Template FlowSet Example.................................48 125 17.3 Data FlowSet Example.....................................48 126 17.4 Options Template FlowSet Example.........................49 127 17.5 Data FlowSet with Options Data Records Example...........50 128 18. References.................................................51 129 18.1 Normative References.....................................51 130 18.2 Informative References...................................51 131 19. Acknowledgments............................................52 133 1. 134 Points of Discussion 136 1.1 137 Open Issues 139 This section covers the open issues, still to be resolved/updated in 140 this draft: 142 Issues in the Terminology section 144 PROTO-1: Is flowSet the right term to use? 145 - leave as is 146 - Record Set 147 - Record Array 148 - Record Collection 149 - Record List 150 PROTO-2: Some discrepancies between data types, field type and 151 Information 152 Element terminology. 153 - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO) 154 - suggestion: use field type instead of field Id in IPFIX-INFO 155 - rename 'type' to 'data type' and 'info elements' to 'fields' 156 in IPFIX-INFO 157 PROTO-3: IP encapsulated packet 158 - IP Traffic Flow definition speaks of IP packets 159 - Metering Process definitions say: 160 Input to the metering process are packets 161 - We don't want to limit ourselves to IPv4 and IPv6 163 Issues in the Transport Protocol section 165 PROTO-4: TCP and UDP are is not yet covered 166 PROTO-5: Error recovery, for example what to do if a collector 167 receives a message it can't decode. 168 Per protocol issue, ie TCP reset the session because it's a 169 stream protocol and can't recover. 170 PROTO-6: Section 5.2.3.3, Association: What happens if the Exporter 171 gets no response 172 from any Collector? 173 I think we should specify a (not-too-aggressive) retry 174 algorithm. 175 PROTO-7: Dropping data before export: What to do with sequence 176 numbers? 177 PROTO-8: Why having a stream per SID? 178 PROTO-9: IPFIX message should have MTU size. 179 PROTO-10: How to re-establish a lost connection? Procedure per 180 transport protocol? 182 Issues in the Failover section 184 PROTO-11: (initial version required) Section needs to be written 185 If we tackle reliability/failover a state diagram is needed. 187 Issues in the Message Layout section 189 PROTO-12: Do we need the IETF exclusive template flowset format? 190 suggested solution: 191 - reserve flowset ID 0 & 1 for compatibility with NFv9 192 - try to make flowset ID 2 & 3 definition fully compatible with 193 NFv9 194 - add note that if you implement ID 2/3 correctly, you can also 195 process ID 0/1. 196 PROTO-13: How to distinguish IETF field IDs from vendor field IDs 197 - Specify method for detecting the difference in section 8. 198 - Add a note that there is a common ID space for for field types 199 used in data templates and option templates 200 - (Editorial) make clear that Section 8.2 also applies to option 201 templates 202 PROTO-14: Why do we need padding? Should we shift it to MAY? 203 limit the size of the padding? Yes 204 solution: 205 - padding shorter than actual Record Length 206 - fill with 0 207 - only at end of flowset 208 - applies to all flowsets 209 - padding is OPTIONAL (MAY) , not RECOMMENDED (SHOULD) 211 Issues in the IPFIX Message Format section 213 PROTO-15: Remove Reserved 2 octets in Vendor specific option 214 template flowset and add padding at the end 215 PROTO-16: relationship between several different scopes in one 216 record 217 PROTO-17: redefine scope values? 218 - 1 System 219 2 IP interface 220 3 observation domain (SID) (preciously called line card) 221 4 reserved (previously used for cache) 222 5 template 223 6 metering process? 224 7 flow recording process? 225 8 exporting process? 226 9 observation point? 228 PROTO-18: Can we have an optional length of 0 bytes for the scope 229 section in the option template? 230 PROTO-19: Do we really need different templates formats for flows 231 and options? 232 PROTO-20 Do we really need different record formats for flows and 233 options? 235 Issues in the Specific Reporting Requirement section 237 PROTO-21: Do we need to define some mandatory content of the 238 metering process statistics option template? 239 - Maurizio suggested text on the mailing list 240 PROTO-22: Exporter ID (ie IP address of exporter) 242 Issues in the Export Packet "Export Time" Computation and Flow 243 Record Time section 245 PROTO-23: Finalize the time details 247 Issues in the Linkage with the Information Model section 249 PROTO-24: Section 11 "Linkage with the information model" must be 250 completed with types used in [IPFIX-INFO] 252 Issues in the Template Management section 254 PROTO-25: The section 11 "Template Management" will have to updated 255 according to the transport protocol. 256 - For example, the point 2 of the section "Template Management". 257 Remark: the template management will vary with TCP, SCTP, 258 etc... 259 Must have both sections updated: transport updated and 260 template management sections (BTW, this is the same for 261 the failover section). 263 Issues in the IANA section 265 PROTO-26: IANA considerations section to be updated: have a look at 266 RFC 2434, which sets out guidelines for IANA Considerations. 267 Also, searching the RFCs for 'IANA Considerations' brings 268 up quite a few RFCs to look at as models. 270 Issues - Miscellaneous 272 PROTO-27: Need an example with the Vendor Specified Information 273 Element 274 PROTO-28: Packet Sampling. This is mentioned in both the 275 Requirements I-D and the AS I-D. We need to decide how it should be 276 covered in the IPFIX drafts. 278 1.2 279 Action Items 281 This section covers the action items for this draft 282 PROTO-29: number all the figures 283 PROTO-30: Review the requirements draft to see what we miss, once 284 it's an I-RFC 286 2. 287 Introduction 289 A data network with IP traffic, primarily consists of IP Flows 290 passing through the network elements of the network. It is often 291 interesting, useful or even a requirement to have access to 292 information about these flows that pass through the network elements 293 for administrative or other purposes. The IPFIX collecting process 294 should be able to receive the flow information passing through 295 multiple network elements within the data network. This requires an 296 uniformity in the method of representing the flow information and 297 the means of communicating the flows from the network elements to 298 the collection point. This document specifies the protocol to 299 achieve these afore mentioned requirements. This document specifies 300 in detail the representation of different flows, the additional data 301 required for flow interpretation, packet format, transport 302 mechanisms used, security concerns, etc. 304 2.1 305 IPFIX Documents Overview 307 The IPFIX protocol provides network administrators with access to IP 308 flow information. The architecture for the export of measured IP 309 flow information out of an IPFIX exporting process to a collecting 310 processing is defined in [IPFIX-ARCH], per the requirements defined 311 in [IPFIX-REQ]. [IPFIX-PROTO] specifies how IPFIX flow record data, 312 options record data and control information is carried via a 313 congestion-aware transport protocol from IPFIX exporting process to 314 IPFIX collecting process. IPFIX has a formal description of IPFIX 315 information elements (fields), their name, type and additional 316 semantic information, as specified in [IPFIX-INFO]. Finally [IPFIX- 317 AS] describes what type of applications can use the IPFIX protocol 318 and how they can use the information provided. It furthermore shows 319 how the IPFIX framework relates to other architectures and 320 frameworks. 322 3. 323 Terminology 325 The definition of the basic terms like IP Traffic Flow, Exporting 326 Process, Collecting Process, Observation Points etc. are 327 semantically identical with that found in the IPFIX requirements 328 document [IPFIX-REQ]. Some of the terms have been expanded for more 329 clarity when defining the protocol. Additional terms required for 330 the protocol has also been defined. For the same terms defined in 331 both this document and [IPFIX-ARCH], the definitions are identical 332 with [IPFIX-ARCH]. 334 The terminology summary table in Section 3.1 gives a quick overview 335 of the relationships between some of the different terms defined. 337 Observation Point 339 The Observation Point is a location in the network where IP packets 340 can be observed. Examples are a line to which a probe is attached, 341 a shared medium such as an Ethernet-based LAN, a single port of a 342 router, or a set of interfaces (physical or logical) of a router. 344 Note that one Observation Point may be a superset of several 345 other Observation Points. For example one Observation Point can be 346 an entire line card. This would be the superset of the 347 individual Observation Points at the line card's interfaces. 349 Observation Domain 351 The set of Observation Points, which is the largest aggregatable set 352 of Flow information at the Metering Process is termed an Observation 353 Domain. Each Observation Domain presents itself as a unique ID to 354 the Collecting Process for identifying the IPFIX Messages it 355 generates. 357 For example, a router line card composed of several interfaces with 358 each interface being an Observation Point. Every Observation Point 359 is associated with an Observation Domain. 361 IP Traffic Flow or Flow 363 There are several definitions of the term 'flow' being used by the 364 Internet community. Within the context of IPFIX we use the 365 following one: 367 A flow is defined as a set of IP packets passing an observation 368 point in the network during a certain time interval. All packets 369 belonging to a particular flow have a set of common properties. 370 Each property is defined as the result of applying a function to the 371 values of: 373 1. one or more packet header field (e.g. destination IP address), 374 transport header field (e.g. destination port number), or 375 application header field (e.g. RTP header fields [RFC1889]) 377 2. one or more characteristics of the packet itself (e.g. number 378 of MPLS labels, etc...) 380 3. one or more of fields derived from packet treatment (e.g. next 381 hop IP address, the output interface, etc...) 383 A packet is defined to belong to a flow if it completely satisfies 384 all the defined properties of the flow. 386 This definition covers the range from a flow containing all packet 387 observed at a network interface to a flow consisting of just a 388 single packet between two applications with a specific sequence 389 number. 391 Flow Key 393 Each of the fields which belong to 395 1. Packet header (e.g. destination IP address) 396 2. Property of the packet itself (e.g. packet length) 397 3. Derived from packet treatment (e.g. AS number) 398 which is used to define a Flow is termed as Flow Key. 400 Flow Type 401 A function F which would take input as a set of Flow Keys and 402 produce as output one or more Flows depending on the combination of 403 values for the set of Flow Keys. 405 Flow Record 407 A Flow Record contains information about a specific Flow that was 408 observed at an Observation Point. A Flow Record contains measured 409 properties of the Flow (e.g. the total number of bytes of all 410 packets of the Flow) and usually characteristic properties of the 411 Flow (e.g. source IP address). 413 Metering Process 415 The Metering Process generates Flow Records. Input to the process 416 are packet headers observed at an Observation Point and packet 417 treatment at the Observation Point, for example the selected output 418 interface. 419 The Metering Process consists of a set of functions that includes 420 packet header capturing, timestamping, sampling, classifying, and 421 maintaining Flow Records. 423 The maintenance of Flow Records may include creating new records, 424 updating existing ones, computing Flow statistics, deriving further 425 Flow properties, detecting Flow expiration, passing Flow Records to 426 the Exporting Process, and deleting Flow Records. 428 Exporting Process 430 The Exporting Process sends Flow Records to one or more Collecting 431 Processes. The Flow Records are generated by one or more Metering 432 Processes. 434 IPFIX Device 436 A device hosting at least an Observation Point, a Metering Process 437 and an Exporting Process. Typically, corresponding Observation 438 Point(s), Metering Process(es) and Exporting Process(es) are co- 439 located at this device, for example at a router. 441 IPFIX Node 443 An IPFIX node is a host that implements the IPFIX protocol 444 which means it contains an Exporting Process or a Collecting 445 Process or both. 447 Collecting Process 448 The Collecting Process receives Flow Records from one or more 449 Exporting Processes. The Collecting Process might store received 450 Flow Records or further process them, but these actions are out of 451 the scope of this document. 453 Collector 455 The device which hosts one or more Collecting Processes. 457 Flow Recording Process 459 The Flows generated from the metering device(s) in an Observation 460 Domain could be collected into one or more database before 461 exporting. This functional block in addition to maintaining the Flow 462 database(s) does Flow aggregation, maintain the aggregate statistics 463 etc. 465 This block is optional for an IPFIX device. 467 Template 469 Template is an ordered n-tuple (e.g. , TLV), used to 470 completely identify the structure and semantics of a particular 471 information that needs to be communicated from the IPFIX Device to 472 the Collector. Each template is uniquely identifiable by some means 473 (e.g. by using a Template ID). 475 Control Information, Data Stream 477 The information that needs to be exported from the IPFIX device can 478 be classified into the following categories: 480 - Control Information: 481 This includes the Flow type definition, selection criteria for 482 packets within the Flow sent by the Exporting Process and any IPFIX 483 protocol messages (e.g. keepalives). The 'control' stream carries 484 all the information needed for the end-points to understand the 485 IPFIX protocol, and specifically for the receiver to understand and 486 interpret the data sent by the sender. 488 - Data Stream: 490 This includes data records carrying the field values for the various 491 observed Flows at each of the Observation Point. A sequence of such 492 records may also be described as a Data Stream. 494 IPFIX Message 496 An IPFIX Message is a message originating at the Exporting Process 497 that carries the IPFIX records of this Exporting Process and whose 498 destination is the Collecting Process. An IPFIX Message is 499 encapsulated within a transport layer header. 501 Message Header 503 The Message Header is the first part of an IPFIX Message, which 504 provides basic information about the message such as the IPFIX 505 version, length of the message, message sequence number, etc. 507 Template Record 509 A Template Record defines the structure and interpretation of fields 510 in a Flow Data Record. 512 Flow Data Record 514 A Flow Data Record is a data record that contains values of the Flow 515 parameters corresponding to a Template Record. 517 Options Template Record 519 An Options Template Record defines the structure and interpretation 520 of fields in an Options Data Record, including defining how to scope 521 the applicability of the Options Data Record. 523 Options Data Record 525 The Options Data Record is a data record that contains values and 526 scope information of the Flow measurement parameters, corresponding 527 to an Options Template Record. 529 FlowSet 530 FlowSet is a generic term for a collection of records that have a 531 similar structure. In an IPFIX Message, one or more FlowSets follow 532 the Message Header. 533 There are three different types of FlowSets: Template FlowSet, 534 Options Template FlowSet, and Data FlowSet. 536 Template FlowSet 538 A Template FlowSet is a collection of one or more Template Records 539 that have been grouped together in an IPFIX Message. 541 Options Template FlowSet 543 An Options Template FlowSet is a collection of one or more Options 544 Template Records that have been grouped together in an IPFIX 545 Message. 547 Data FlowSet 549 A Data FlowSet is one or more records, of the same type, that are 550 grouped together in an IPFIX Message. Each record is either a Flow 551 Data Record or an Options Data Record previously defined by a 552 Template Record or an Options Template Record. 554 Information Element 556 An Information Element is a protocol and encoding independent 557 description of an attribute which may appear in an IPFIX Flow 558 Record. The IPFIX information model [IPFIX-INFO] defines the base 559 set of Information Elements for IPFIX. The type associated with an 560 Information Element indicates constraints on what it may contain and 561 also determine the valid encoding mechanisms for use in IPFIX. 563 3.1 564 Terminology Summary Table 566 +------------------+---------------------------------------------+ 567 | | Contents | 568 | +--------------------+------------------------+ 569 | FlowSet | Template Record | Data Record | 570 +------------------+--------------------+------------------------+ 571 | | | Flow Data Record(s) | 572 | Data FlowSet | / | or | 573 | | | Options Data Record(s) | 574 +------------------+--------------------+------------------------+ 575 | Template FlowSet | Template Record(s) | / | 576 +------------------+--------------------+------------------------+ 577 | Options Template | Options Template | / | 578 | FlowSet | Record(s) | | 579 +------------------+--------------------+------------------------+ 581 A Data FlowSet is composed of an Options Data Record(s) or Flow Data 582 Record(s). No Template Record is included. A Template Record defines 583 the Flow Data Record, and an Options Template Record defines the 584 Options Data Record. 586 A Template FlowSet is composed of Template Record(s). No Flow or 587 Options Data Record is included. 589 An Options Template FlowSet is composed of Options Template 590 Record(s). No Flow or Options Data Record is included. 592 4. 593 Criteria for Flow Expiration and Export 595 4.1 596 Flow Expiration 598 A Flow is considered as expired under the following conditions: 600 1. If the Metering Process can detect the end of a Flow. For 601 example, if the FIN or RST bit is detected in a TCP 602 [TCP] connection. 604 2. If no packets belonging to the Flow have been observed for a 605 certain period of time. This time period SHOULD be configurable at 606 the Metering Process. Note that if the time period is set to 0, the 607 Metering Process will create a Flow for every single packet 608 observed. 610 3. If the Metering Process experiences internal constraints, a Flow 611 MAY be expired forcibly. For example, counters wrapping or low 612 memory. 614 4.2 615 Flow Export 617 A flow can be exported because it expired due to the reasons 618 mentioned in Flow Expiration section. The exporting process decides 619 when and whether to export an expired flow. For example: the 620 exporting process exports a portion of the expired flows every 'x' 621 seconds. 623 For long-lasting Flows, the Exporting Process SHOULD export the Flow 624 Records on a regular basis or based on some export policy. This 625 periodicity or export policy SHOULD be configurable at the Metering 626 Process. 628 5. 629 Transport Protocol 631 The IPFIX Protocol Specifications have been designed to be transport 632 protocol independent. Note that the Exporter can export to multiple 633 Collecting Processes, using independent transport protocols. 635 5.1 636 Transport Compliance and Transport Usage 638 We must differentiate between what must be implemented (so that 639 operators can interoperably deploy compliant implementations from 640 different vendors) and what should or could be used in various 641 operational environments. We must also make sure that ALL 642 implementations can operate in a congestion-aware and congestion 643 avoiding mode. 645 SCTP [RFC2960] MUST be implemented by all compliant implementations. 646 UDP [UDP] and TCP [TCP] MAY also be implemented by compliant 647 implementations. 649 SCTP SHOULD be used in deployments where exporters and collectors 650 are communicating over links which are susceptible to congestion. 652 TCP MAY be used in deployments where exporters and collectors 653 communicate over links which are susceptible to congestion, but SCTP 654 is preferred, due to its ability to limit back pressure on exporters 655 (especially when using PR-SCTP [SCTP-PR]) and its message vs. stream 656 orientation. 658 Other non-congestion aware protocols (like UDP) MAY be used in 659 deployments where exporters and collectors always communicate over 660 dedicated links which are not susceptible to congestion. 662 5.2 663 TCP 665 To be completed. 667 TCP [TCP] 669 5.3 670 SCTP 672 This section describes how IPFIX can be transported over SCTP 673 [RFC2960] using traditional reliable mode. 675 IPFIX can also be transported over the partial reliable or 676 unreliable mode [PR-SCTP]. These last 2 modes will be briefly 677 discussed, while waiting for [PR-SCTP] to become a standard. 679 5.3.1 Congestion Avoidance 681 The SCTP transport protocol provides the required level of 682 congestion avoidance by design. 684 5.3.2 Reliability 686 The SCTP transport protocol is by default reliable, but has the 687 capability to operate in unreliable and partially reliable modes 688 [PR-SCTP]. 690 Using reliable SCTP streams (referred to hereafter as "streams") for 691 the IPFIX export is not in itself a guarantee that all records are 692 delivered. If there is congestion on the link from the exporter to 693 the collector, or if a significant amount of retransmissions are 694 needed, the send queues on the Exporting Process may fill up. In 695 that case it's up to the Exporting Process to decide what to do. It 696 MAY either halt export (buffer the data until there is space in the 697 send queues again) or discard IPFIX Messages away instead of 698 inserting them into the send queue. If any data is not inserted into 699 the send queues, the sequence numbers used for export must reflect 700 the loss of data. 702 5.3.3 Exporting Process 704 5.3.3.1 MTU size 706 Each IPFIX Message SHOULD be equal to or less than the local MTU in 707 size. When an IPFIX Message is transmitted over a network with an 708 MTU smaller than the local MTU, IP fragmentation may be used. 710 5.3.3.2 Source ID 712 The IPFIX Message MUST contain a Message Header, which includes a 713 source id (SID). The SID indicates from which Observation Domain the 714 data is being exported, and should be kept unique for each such 715 Observation Domain. 717 If a Metering Process consists of a single Observation Domain, a 718 single SID value MUST be used for all IPFIX Messages. The Exporting 719 Process will typically open one association to the collector, but 720 more are possible, in which one or more streams can be used. The 721 Exporting Process has the choice of transmitting parts of the export 722 data in separate streams or all data in one stream. 724 If a Metering Process consists of multiple Observation Domains, one 725 SID value for each Observation Domain MUST be used. The Exporting 726 Process will typically open one association, but more are possible, 727 in which at least one stream per Observation Domain is used. 729 The Exporting Process has the choice of using more than one stream 730 per Observation Domain, but data from multiple Observation Domains 731 should not be transmitted over the same stream. 733 5.3.3.3 Association 735 The Exporting Process MAY create one or more associations 736 (connection "bundle" in SCTP terminology) to the Collecting Process. 737 The Collecting Process MAY not initiate the connection. Inside each 738 association one or more streams MAY be requested by the Exporting 739 Process. If the Collecting Process can not support the requested 740 number of streams, it MAY choose to refuse the connection and the 741 Exporting Process should try to reduce, if possible, the number of 742 streams needed to perform the export. 744 5.3.3.4 Stream 746 An Observation Domain MUST use at least one stream, but MAY use 747 multiple streams, to export data records. The Observation Domain 748 MUST use the same SID value for all streams used. 750 An Exporting Process must not transmit messages with different SID 751 values in one stream, the Collecting Process should however verify 752 that the SID values are the expected values. 754 5.3.3.5 Template 756 Since the SCTP association is connection oriented the available 757 Template Records MUST be transmitted from each Observation Domain to 758 the Collecting Process immediately after the association is 759 established. 761 As a minimum the Template Records MUST be transmitted immediately 762 after they start to exist on the Metering Process and SHOULD 763 preferably be transmitted before any data, using the new Template 764 Record, have been transmitted. The Collecting Process SHOULD however 765 accept data without a Template Record. 767 When using a reliable mode for Template Record export, or if the 768 exporter knows that the IPFIX Message containing the templates was 769 positively acknowledged by the SCTP layer, it is not necessary to 770 periodically export the Template Records. 772 5.3.4 Collecting Process 774 The Collecting Process SHOULD listen for a new association request 775 from the Exporting Process. The Exporting Process will request a 776 number of streams to use for export. If the Collecting Process 777 doesn't support the number of streams inside the association, the 778 Collecting Process MUST refuse the connection and continue listen 779 for a new request. 781 When data is received from an association, the Collecting Process 782 MUST correlate data, with the same SID (Source ID) value, from 783 multiple streams into one export Flow from an Observation Domain. 784 This allows the Observation Domain to use separate streams for 785 different types of information. 787 The Collecting Process SHOULD verify that the received IPFIX 788 Messages inside one stream does not have differing SID values. The 789 Exporting Process MUST not transmit messages inside one stream with 790 multiple SID values. The correlated Flow Records are then treated 791 like a normal export Flow. 793 5.3.5 SCTP Partially Reliable 795 This mode will not be discussed any further until [PR-SCTP] becomes 796 a standard, even if this mode offers a few advantages: 797 freedom to use SCTP as a reliable, single stream transport, as well 798 as multiple streams with different properties, for example in terms 799 of reliability, carrying different data types dependant on their 800 importance for the system. 801 Unreliable or partial reliability may be chosen for one or more 802 streams inside an association. Unreliable transport MAY be preferred 803 where large amount of data is to be exported and keeping send queues 804 is either an unnecessary overhead or impractical. Partial 805 reliability MAY be chosen where a small amount of queuing is 806 possible. 808 Naturally it is better to send templates over a reliable stream and 809 send the data on an unreliable (or partial reliable) stream. When an 810 exporter handles data with different properties it might even be 811 preferable to send them over different streams according to those 812 properties. 814 Example: an Exporting Process can use two streams per Observation 815 Domain. A reliable stream could be used for exporting templates, to 816 reduce the likelihood of loss and to remove the need for blind 817 retransmissions, and a partial or unreliable stream for data, to 818 avoid buffering of large amounts of data. 820 5.4 821 UDP 823 To be completed. 824 UDP [UDP] 826 6. 827 Failover 829 When to fail over? 830 How to fail back? 831 How to ensure stability of the failover mechanism (prevent 832 oscillations)? 833 Does the exporter open connections to all the potential collectors 834 and keep them primed with template info? 836 6.1 837 Simple Failover based on the transport protocol 839 In case the transport protocol is connection oriented. 840 So in case of TCP [TCP] or SCTP [RFC2960]. 841 To be completed. 843 6.2 844 Something else? 846 Potentially based on some application level ACK from the exporter? 848 7. 849 Message Layout 851 An IPFIX Message consists of a Message Header followed by one or 852 more FlowSets. The FlowSets can be any of the possible three types: 853 Template, Data, or Options Template. 855 IPFIX Message: 856 +--------+-------------------------------------------+ 857 | | +----------+ +---------+ +----------+ | 858 |Message | | Template | | Data | | Options | | 859 | Header | | FlowSet | | FlowSet | | Template | ... | 860 | | | | | | | FlowSet | | 861 | | +----------+ +---------+ +----------+ | 862 +--------+-------------------------------------------+ 864 A FlowSet ID is used to distinguish the different types of FlowSets. 865 FlowSet IDs lower than 256 are reserved for special FlowSets, such 866 as the Template FlowSet (ID 0) and the Options Template FlowSet (ID 867 1). The Data FlowSets have a FlowSet ID greater than 255. 869 The format of the Template, Data, and Options Template FlowSets will 870 be discussed later in this document. The Exporter MUST code all 871 binary integers of the Message Header and the different FlowSets in 872 network byte order (also known as the big-endian byte ordering). 874 Following are some examples of IPFIX Messages: 876 1. An IPFIX Message consisting of interleaved Template, Data, and 877 Options Template FlowSets-A newly created Template is exported as 878 soon as possible. So if there is already an IPFIX Message with a 879 Data FlowSet that is being prepared for export, the Template and 880 Option FlowSets are also interleaved with this information, subject 881 to availability of space. 883 IPFIX Message: 885 +--------+--------------------------------------------------------+ 886 | | +----------+ +---------+ +-----------+ +---------+ | 887 |Message | | Template | | Data | | Options | | Data | | 888 | Header | | FlowSet | | FlowSet | ... | Template | | FlowSet | | 889 | | | | | | | FlowSet | | | | 890 | | +----------+ +---------+ +-----------+ +---------+ | 891 +--------+--------------------------------------------------------+ 893 2. An IPFIX Message consisting entirely of Data FlowSets-After the 894 appropriate Template Records have been defined and transmitted to 895 the Collecting Process, the majority of IPFIX Messages consists 896 solely of Data FlowSets. 898 IPFIX Message: 899 +--------+----------------------------------------------+ 900 | | +---------+ +---------+ +---------+ | 901 |Message | | Data | ... | Data | ... | Data | | 902 | Header | | FlowSet | ... | FlowSet | ... | FlowSet | | 903 | | +---------+ +---------+ +---------+ | 904 +--------+----------------------------------------------+ 906 3. An IPFIX Message consisting entirely of Template and Options 907 Template FlowSets-The Exporter MAY transmit a message containing 908 Template and Options Template FlowSets periodically to help ensure 909 that the Collecting Process has the correct Template Records and 910 Options Template Records when the corresponding Flow Data records 911 are received. 913 IPFIX Message: 914 +--------+-------------------------------------------------+ 915 | | +----------+ +----------+ +----------+ | 916 |Message | | Template | | Template | | Options | | 917 | Header | | FlowSet | ... | FlowSet | ... | Template | | 918 | | | | | | | FlowSet | | 919 | | +----------+ +----------+ +----------+ | 920 +--------+-------------------------------------------------+ 922 8. 923 IPFIX Message Format 925 8.1 926 Header Format 928 0 1 2 3 929 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Version Number | Length | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Export Time | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Sequence Number | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Source ID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Message Header Field Descriptions 943 Version 944 Version of Flow Record format exported in this message. The 945 value of this field is 0x000a for the current version. 947 Length 948 Total Length is the length of the IPFIX message, measured in 949 octets, including message Header and FlowSet(s). 951 Export Time 952 Time in seconds since 0000 UTC 1970, at which the Export 953 Packet leaves the Exporter. 955 Sequence Number 956 Incremental sequence counter of all IPFIX Messages sent from 957 the current Observation Domain by the Exporting Process. 958 This value MUST SHOULD be used by the Collecting Process to 959 identify whether any IPFIX Messages have been missed. 961 Source ID 962 A 32-bit value that identifies the Exporter Process 963 Observation Domain. Collecting Process SHOULD use the 964 combination of the source IP address and the Source ID field 965 to separate different export streams originating from the 966 same Exporting Process. 968 8.2 969 Field Type Format 971 This section describes the Field Type format for both IETF specified 972 Information Elements [IPFIX-INFO] and Vendor Specified Information 973 Elements. Vendors need the ability to define proprietary Information 974 Elements, because, for example, they are delivering pre-standards 975 product, or the Information Element is in some way commercially 976 sensitive. 978 The Field Ids used to identify Information Elements are divided into 979 two non-overlapping ranges: the IETF specified range and the vendor 980 specified range. This partitioning of the identifiers into two 981 ranges allows the Collecting Process to discriminate between an IETF 982 specified Information Element and a Vendor Specified Information 983 Element. The vendor specified range is shared by all vendors, and 984 thus needs an accompanying vendor identifier to uniquely identify 985 it. 987 The format of an IETF defined Field Type is shown in Fig A. 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Field Type | Field Length | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Fig A: IETF defined Field Type 997 Where: 999 Field Type 1000 A numeric value that represents the type of the field. Refer 1001 to [IPFIX-INFO]. 1003 Field Length 1004 The length of the corresponding Field Type, in bytes. Refer 1005 to [IPFIX-INFO]. 1007 The format of the Vendor Specified Field Type is shown in Fig B. 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Field Type | Field Length | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Enterprise Number | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Fig B: Vendor Specified Field Type 1018 Where: 1020 Field Type 1021 A numeric value that represents the type of the field. Refer 1022 to [IPFIX-INFO]. 1024 Field Length 1025 The length of the corresponding Field Type, in bytes. Refer 1026 to [IPFIX-INFO]. 1028 Enterprise Number 1029 IANA enterprise number [PEN] of the authority defining the 1030 field type in this template record. 1032 8.3 1033 Template FlowSet Format 1035 One of the essential elements in the IPFIX format is the Template 1036 FlowSet. Templates greatly enhance the flexibility of the Flow 1037 Record format because they allow the Collecting Process to process 1038 Flow Records without necessarily knowing the interpretation of all 1039 the data in the Flow Record. 1041 8.3.1 IETF Exclusive Template FlowSet Format 1043 The IETF exclusive Template FlowSet MAY be used when the template 1044 contains only IETF defined Information Elements. This format is 1045 provided for backwards compatibility [NETFLOW9]. The format of the 1046 IETF exclusive Template FlowSet is shown in Figure C. 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | FlowSet ID = 0 | Length | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Template ID 1 | Field Count | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Field Type 1 | Field Length 1 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Field Type 2 | Field Length 2 | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | ... | ... | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Field Type N | Field Length N | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Template ID 2 | Field Count | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Field Type 1 | Field Length 1 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Field Type 2 | Field Length 2 | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | ... | ... | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Field Type M | Field Length M | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | ... | ... | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Template ID K | Field Count | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | ... | ... | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Figure C: IETF Exclusive Template FlowSet Format 1081 Field Descriptions 1083 FlowSet ID 1084 FlowSet ID value of 0 is reserved for the Template FlowSet. 1086 Length 1087 Total length of this FlowSet. Because an individual Template 1088 FlowSet MAY contain multiple Template Records, the Length 1089 value MUST be used to determine the position of the next 1090 FlowSet record, which could be any type of FlowSet. Length 1091 is the sum of the lengths of the FlowSet ID, the Length 1092 itself, and all Template Records within this FlowSet. 1094 Template ID 1095 Each of the newly generated Template Records is given a 1096 unique Template ID. This uniqueness is local to the 1097 Observation Domain that generated the Template ID. 1098 Template IDs 0-255 are reserved for Template FlowSets, 1099 Options FlowSets, and other reserved FlowSets yet to be 1100 created. Template IDs of Data FlowSets are numbered from 256 1101 to 65535. 1103 Field Count 1104 Number of fields in this Template Record. Because a Template 1105 FlowSet usually contains multiple Template Records, this 1106 field allows the Collecting Process to determine the end of 1107 the current Template Record and the start of the next. 1109 Field Type 1110 A numeric value that represents the type of the field. Refer 1111 to [IPFIX-INFO]. 1113 Field Length 1114 The length of the corresponding Field Type, in bytes. Refer 1115 to [IPFIX-INFO]. 1117 8.3.2 Vendor Specified Template FlowSet Format 1119 A vendor specified Template FlowSet MUST be used when the template 1120 contains one or more Vendor Specified Information Elements. A vendor 1121 specified template MAY exclusively contain IETF defined Field Types. 1122 A vendor specified template MAY contain Vendor Specified Information 1123 Elements from multiple vendors. 1125 The format of the Vendor Specified Template FlowSet is shown in 1126 Figure D. 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | FlowSet ID = 2 | Length | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Template ID 1 | Field Count | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Field Type 1 | Field Length 1 | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Enterprise Number 1.1 | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Field Type 2 | Field Length 2 | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | ... | ... | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Field Type N | Field Length N | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Enterprise Number 1.N | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Template ID 2 | Field Count | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Field Type 1 | Field Length 1 | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Field Type 2 | Field Length 2 | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Enterprise Number 2.2 | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | ... | ... | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Field Type M | Field Length M | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Enterprise Number 2.M | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Figure D: Vendor Specified Template Flowset 1164 The definition of the fields in the Vendor Specified Template 1165 FlowSet is identical to those described in the IETF exclusive 1166 Template FlowSet Format Field Descriptions except: 1168 FlowSet ID 1169 FlowSet ID value of 2 is reserved for the Vendor Specified 1170 Template FlowSet 1172 Enterprise Number 1173 IANA enterprise number [PEN] of the authority defining the 1174 field type in this template record. 1176 8.4 1177 Data FlowSet Format 1179 The format of the Data FlowSet is as follows: 1181 0 1 2 3 1182 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 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | FlowSet ID = Template ID | Length | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Record 1 - Field Value 3 | ... | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Record 2 - Field Value 3 | ... | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Record 3 - Field Value 1 | ... | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | ... | Padding | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 Note that not all Field Values do necessarily have a length of 16 1200 bit. 1202 Data FlowSet Field Descriptions 1204 FlowSet ID = Template ID 1205 Each Data FlowSet is associated with a FlowSet ID. The 1206 FlowSet ID maps to a (previously generated) Template ID. The 1207 Collecting Process MUST use the FlowSet ID to find the 1208 corresponding Template Record and decode the Flow Records 1209 from the FlowSet. 1211 Length 1212 The length of this FlowSet. 1213 Length is the sum total of lengths of FlowSet ID, Length 1214 itself, all Flow Records within this FlowSet, and the 1215 padding bytes, if any. 1217 Record N - Field Value M 1218 The remainder of the Data FlowSet is a collection of Flow 1219 Data Record(s), each containing a set of field types and 1220 values. The Type and Length of the fields have been 1221 previously defined in the Template Record referenced by the 1222 FlowSet ID or Template ID. 1224 Padding 1225 The Exporting Process SHOULD insert some padding bytes so 1226 that the subsequent FlowSet starts at a 4-byte aligned 1227 boundary. It is important to note that the Length field 1228 includes the padding bits. 1230 Interpretation of the Data FlowSet format can be done only if the 1231 Template FlowSet corresponding to the Template ID is available at 1232 the Collecting Process. 1234 8.5 1235 Options Template FlowSet Format 1237 The Options Template Record (and its corresponding Options Data 1238 Record) is used to supply information about the Metering Process 1239 configuration or Metering Process specific data, rather than 1240 supplying information about IP Flows. 1241 For example, the Options Template FlowSet can report the sample rate 1242 of a specific interface, if sampling is supported, along with the 1243 sampling method used. 1245 8.5.1 IETF Exclusive Options Template FlowSet Format 1247 The IETF exclusive Options Template FlowSet Format MAY be used 1248 when the template contains only IETF defined options. This format 1249 is provided for backwards compatibility [NETFLOW9]. The format of 1250 the IETF exclusive Options Template FlowSet Format is shown in 1251 Figure E. 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | FlowSet ID = 1 | Length | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Template ID | Option Scope Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Option Length | Scope 1 Field Type | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Scope 1 Field Length | ... | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Scope N Field Length | Option 1 Field Type | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Option 1 Field Length | ... | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Option M Field Length | Padding | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 Figure E: IETF Exclusive Options Template FlowSet 1273 The IETF Exclusive Options Template FlowSet Field Definitions are 1274 as follows: 1276 FlowSet ID = 1 1277 A FlowSet ID value of 1 is reserved for the Options 1278 Template. 1280 Length 1281 Total length of this FlowSet. Each Options Template FlowSet 1282 MAY contain multiple Options Template Records. Thus, the 1283 Length value MUST be used to determine the position of the 1284 next FlowSet record, which could be either a Template 1285 FlowSet or Data FlowSet. 1286 Length is the sum total of lengths of FlowSet ID, the Length 1287 itself, and all Options Template Records within this FlowSet 1288 Template ID. 1290 Template ID 1291 Template ID of this Options Template. This value is greater 1292 than 255. 1294 Option Scope Length 1295 The length in bytes of any Scope fields definition contained 1296 in the Options Template Record (The use of "Scope" is 1297 described below). 1299 Option Length 1300 The length (in bytes) of any options field definitions 1301 contained in this Options Template Record. 1303 Scope 1 Field Type 1304 The relevant portion of the Exporting Process/Metering 1305 Process to which the Options Data Record refers. 1306 Currently defined values are: 1307 1 System 1308 2 Interface 1309 3 Line Card 1310 4 Cache 1311 5 Template 1312 For example, the Metering Process can be implemented on a 1313 per-interface basis, so if the Options Template Record were 1314 reporting on how the Metering Process is configured, the 1315 Scope for the report would be 2 (interface). The associated 1316 interface ID would then be carried in the associated Options 1317 Data FlowSet. The Scope can be limited further by listing 1318 multiple scopes that all must match at the same time. Note 1319 that the Scope fields always precede the Option fields. 1321 Scope 1 Field Length 1322 The length (in bytes) of the Scope field, as it would appear 1323 in an Options Data Record. 1325 Option 1 Field Type 1326 A numeric value that represents the type of field that would 1327 appear in the Options Template Record. Refer to [IPFIX- 1328 INFO]. 1330 Option 1 Field Length 1331 The length (in bytes) of the Option Field. 1333 Padding 1334 The Exporting Process SHOULD insert some padding bytes so 1335 that the subsequent FlowSet starts at a 4-byte aligned 1336 boundary. It is important to note that the Length field 1337 includes the padding bits. 1339 8.5.2 Vendor Specified Options Template FlowSet Format 1341 A vendor specified Options Template MUST be used when the template 1342 contains one or more vendor specified options. A vendor specified 1343 Options Template MAY exclusively contain IETF defined Field Types. A 1344 vendor specified template MAY contain Vendor Specified Information 1345 Elements from multiple vendors. 1347 The format of the Vendor Specified Options Template FlowSet is shown 1348 in Figure E. 1350 0 1 2 3 1351 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 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | FlowSet ID = 3 | Length | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Template ID | Option Scope Length | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Option Length | Reserved must be zero | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Scope 1 Field Type | Scope 1 Field Length | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | ... | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Scope N Field Type | Scope N Field Length | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Scope N Enterprise Number | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Option 1 Field Type | Option 1 Field Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Option 1 Enterprise Number | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | ... | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Option N Field Type | Option N Field Length | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 Figure E: Vendor Specified Option Template FlowSet 1378 The definition of the fields in the vendor specified Options 1379 Template FlowSet is identical to those described IETF Exclusive 1380 Options Template FlowSet Format Field Descriptions except: 1382 FlowSet ID = 3 1383 A FlowSet ID value of 3 is reserved for a VI Qualified 1384 Options Template. 1386 Scope N Enterprise Number 1387 IANA enterprise number [PEN] of the authority defining 1388 Scope N. 1390 Option N Enterprise Number 1391 IANA enterprise number [PEN] of the authority defining the 1392 Option N field type. 1394 8.5.3 Options Data Record Format 1396 The Options Data Records are sent in Data FlowSets, on a regular 1397 basis, but not with every Flow Data Record. How frequently these 1398 Options Data Records are exported is configurable. See the Templates 1399 Management" section for more details. 1401 The format of the Data FlowSet containing Options Data Records 1402 follows. 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | FlowSet ID = Template ID | Length | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Record 1 - Scope 1 Value | Record 1 - Scope 2 Value | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | ... |Record 1 - Option Field 1 Value| 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 |Record 1 - Option Field 2 Value| ... | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Record 2 - Scope 1 Value | Record 2 - Scope 2 Value | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | ... |Record 2 - Option Field 1 Value| 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 |Record 2 - Option Field 2 Value| ... | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Record 3 - Scope 1 Value | Record 3 - Scope 2 Value | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | ... |Record 3 - Option Field 1 Value| 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 |Record 3 - Option Field 2 Value| ... | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | ... | Padding | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Options Data Records of the Data FlowSet Field Descriptions 1432 FlowSet ID = Template ID 1433 A FlowSet ID precedes each group of Options Data Records 1434 within a Data FlowSet. The FlowSet ID maps to a previously 1435 generated Template ID corresponding to this Options Template 1436 Record. The Collecting Process MUST use the FlowSet ID to 1437 map the appropriate type and length to any field values that 1438 follow. 1440 Length 1441 The length of this FlowSet. 1443 Length is the sum of the lengths of the FlowSet ID, Length 1444 itself, all the Options Data Records within this FlowSet, 1445 and the padding bytes, if any. 1447 Record N - Option Field M Value 1448 The remainder of the Data FlowSet is a collection of Flow 1449 Records, each containing a set of scope and field values. 1450 The type and length of the fields were previously defined in 1451 the Options Template Record referenced by the FlowSet ID or 1452 Template ID. 1454 Padding 1455 The Exporting Process SHOULD insert some padding bytes so 1456 that the subsequent FlowSet starts at a 4-byte aligned 1457 boundary. It is important to note that the Length field 1458 includes the padding bits. 1460 The Data FlowSet format can be interpreted only if the Options 1461 Template FlowSet corresponding to the Template ID is available at 1462 the Collecting Process. 1464 9. 1465 Specific Reporting Requirements 1467 Some specific Options Templates and Options Templates Records are 1468 necessary to provide extra information about the Flow Records and 1469 about the Metering Process. 1471 The ipfixOption [IPFIX-INFO], always included in these specific 1472 Options Templates, defines the type of information sent in the Option 1473 Template / Option Template Record pair. For example, if the 1474 ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option 1475 Template will specify information about the Metering Process 1476 statistics. The ipfixOption [IPFIX-INFO] MUST always be the first Data 1477 Type in the Option Template so that the Collector could quickly 1478 determine whether or not a specific Option Template is described. And 1479 if the ipfixOption [IPFIX-INFO] is present, which specific Option 1480 Template type it defines. 1482 The minimum set of Data Types is always specified in these Specific 1483 IPFIX Options Templates. Nevertheless, extra Data Types MAY be used in 1484 these specific Options Templates. 1486 9.1 1487 The Metering Process Statistics Option Template 1489 The Metering Process Statistics Option Template defines the Metering 1490 Process Statistics with the export of the following Data Types [IPFIX- 1491 INFO]: 1492 ipfixOption The value MUST be METER_STATS 1493 observationDomain Source ID 1494 lostFlows flows not exported due to resource 1495 starvation 1496 lostFlowsPacket Packets in the lost flows 1497 lostFlowsBytes Bytes in the lost flows 1498 droppedPacketCount Packets dropped by Metering Process 1499 at the Observation Point 1500 droppedByteCount Bytes dropped by Metering Process at the 1501 Observation Domain 1502 time; When this record was generated 1504 The minimum set of Data Type in the Metering Process Statistics Option 1505 Template is: ipfixOption, observationDomain, lostFlows, time 1507 10. 1508 Export Packet "Export Time" Computation and Flow Record Time 1510 10.1 1511 Microsecond Precision 1513 For a Data FlowSet with Flow Records requiring microsecond 1514 precision, the Export Packet "Export Time" field MUST be calculated 1515 so that each Flow Records flowStartUsec [IPFIX-INFO] and flowEndUsec 1516 [IPFIX-INFO] would contain a 32 bit signed microsecond offset from 1517 the "Export Time" base timestamp. Hereafter some pseudo code to 1518 calculate the Export Time in one pass, which would return an 1519 absolute duration of 35 minutes for all Flow Records contained in 1520 the Data FlowSet. Flow Records MUST be exported in different Export 1521 Packet if the absolute duration can not fit in those 35 minutes. 1523 // pseudo code for microsecond offset in IPFIX encoded Flow Records. 1524 // 1526 struct flow{ 1527 uint32 tv_sec; 1528 uint32 tv_usec; 1529 uint32 numbytes; 1530 ... // other information elements... 1531 }; 1533 struct flow flowtable [MAX_TABLE_SIZE]; 1534 int lastflowindex = -1; 1536 writeflows() { 1538 if (lastflowindex < 0) return; 1540 // simply take the second field from the first available flow 1541 // and make this the base time for this collection of flows. 1542 uint32 base_sec = flowtable[0].tv_sec; 1544 writeheaderToSocket(base_sec); // put 32-bit second value in header 1546 for (int i=0; i<=lastflowindex; i++){ 1548 int32 offset = (flowtable[i].tv_sec - base_sec) * 1000000 + 1549 flowtable[i].tv_usec; 1550 writeint32ToSocket(offset); // put the 32-bit time offset in the 1551 record. 1553 // write other information elements... 1554 } 1555 } 1557 A two pass approach calculation for the optimum (center) "Export 1558 Time" base timestamp would allow an absolute duration of 71 minutes 1559 for all Flow Records contained in the Data FlowSet. The two pass 1560 approach MAY be used. 1561 The "Export Time" base timestamp calculation requires that at the 1562 Export Packet exporting time the Exporting Process MUST run down the 1563 list of Flow Records in the Data FlowSet message and adjust the Flow 1564 start and Flow end timestamps. 1566 10.2 1567 Millisecond Precision 1569 For a Data FlowSet with Flow Records requiring a millisecond 1570 precision, the same principles as in section 10.1 "Microsecond 1571 Precision" will be used. 1573 The only difference will be that the Flow start and the Flow end 1574 SHOULD now be represented respectively by the flowStartMsec [IPFIX- 1575 INFO] and flowEndMsec [IPFIX-INFO]. As a consequence of the 1576 millisecond precision, the absolute duration of all Flow Records is 1577 now of about 49 days. The Export Header "Export Time" base time 1578 SHOULD be calculated with the algorithm described in the Section 1579 10.1 "Microsecond Precision". In order to reduce the load on the 1580 Exporter, the Export Header "Export Time" MAY be the time in seconds 1581 since 0000 UTC 1970 at which the Export Packet leaves the Exporter 1582 and not the calculated optimum value anymore as described in section 1583 10.1 "Microsecond Precision". 1585 Alternatively, for a Data FlowSet with Flow Records requiring a 1586 millisecond precision, the microsecond mechanism as described in 1587 section 10.1 MAY be used as such. The Flow Record MAY use the 1588 flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-INFO] rounded at a 1589 millisecond precision. 1591 10.3 1592 Nanosecond Precision 1594 For a Data FlowSet with Flow Records requiring a nanosecond 1595 precision, all Flow Records will contain Flow start flowStartNsec 1596 [IPFIX-INFO] and flowEndNsec [IPFIX-INFO]. The Export Header "Export 1597 Time" will be of no use on the Collector side in this case as 1598 the flowStartNsec [IPFIX-INFO] and flowEndNsec [IPFIX-INFO] both 1599 have a nanosecond precision already. Both flowStartNsec [IPFIX-INFO] 1600 and flowEndNsec [IPFIX-INFO] use the NTP time format which is 1601 represented as a 64-bit value which contains a 32-bit specification 1602 of seconds since 1900 and a 32-bit "fraction" field. Refer to the 1603 NTP specification, RFC1305, section 3.1 "Data Formats". 1605 10.4 1606 Multiple Precisions 1608 When Flow Records requiring different precisions must be exported, 1609 the Exporting Process SHOULD split the Flow Records in different 1610 Data FlowSet according to the precision: millisecond, microsecond 1611 or nanosecond. 1613 11. 1614 Linkage with the Information Model 1616 The information model associates each IPFIX Data Type with a well 1617 defined type, such as hexBinary, long, unsignedInt, etc. 1619 This document defines how fields of a given type are encoded. 1621 11.1 1622 Boolean 1624 A boolean field shall be encoded in a single byte with the value of 1625 0 indicating false and any other value indicating true. 1627 11.2 1628 Byte 1630 A byte value shall be encoded as a single byte representing a value 1631 between -128 and 127. The value is represented in two's complement 1632 notation. 1634 11.3 1635 UnsignedByte 1637 An unsigned byte value shall be encoded as a single byte 1638 representing a value between 0 and 255. 1640 11.4 1641 Short 1643 A short is a 16-bit datum that encodes an integer in the range [- 1644 32768,32767]. The short is represented in two's complement 1645 notation. The most and least significant bytes are 0 and 1, 1646 respectively 1648 EDITOR NOTE: this section 11 must be completed with types used in 1649 [IPFIX-INFO]. 1651 11.5 1652 Reduced Size Encoding of Integral Types 1654 Information Elements containing integral types in the information 1655 model MAY be encoded using fewer bytes than those implied by their 1656 type in the information model definition [IPFIX-INFO], based on the 1657 assumption that the smaller type is sufficient to carry any value 1658 the Exporter may need to deliver. This reduces the network bandwidth 1659 requirement between the Exporter and the Collector. Note that the 1660 information model Data Types definition [IPFIX-INFO] will always 1661 define the maximum encoding size for each Data Type. 1663 For instance the information model [IPFIX-INFO] defines byteCount as 1664 an unsignedLong type, which would require 64-bits. However if the 1665 exporter will never locally encounter the need to send a value 1666 larger than 4294967295, it may chose to send the value instead as an 1667 unsignedInt. For example, a core router would require an 1668 unsignedLong byteCount while an unsignedInt might be sufficient for 1669 an access router. 1671 This behavior is indicated by the Exporter by specifying a type size 1672 smaller than that associated with the assigned type of the field. In 1673 the example above the Exporter would place a length of 4 vs. 8 in 1674 the template. 1676 Reduced sizing MAY only be applied to the following integral types: 1677 short, unsignedShort, int, unsignedInt, long, unsignedLong. In each 1678 case the downcasting must be to a smaller integral type which MUST 1679 have the same signed vs. unsigned properties. 1681 Specifically unsignedLong may be downcast to unsignedInt, 1682 unsignedShort or unsignedByte. A long may be downcast to an int a 1683 short or a byte. The other downcasts follow the same pattern. 1685 12. 1686 Variable Length Data Type 1688 The IPFIX template mechanism is optimized for fixed length 1689 Information Elements [IPFIX-INFO]. Where an Information Element has 1690 a variable length the following mechanism MUST used to carry the 1691 length information. 1693 In the Template FlowSet the length is recorded as 65535. This 1694 reserved length value notifies the Collecting Process that length of 1695 the Information Element will be carried in the Information Element 1696 itself. 1698 In most cases the length of the Information Element will be less 1699 than 256 bytes. The following length encoding mechanism optimizes 1700 the overhead of carrying the Information Element length in this 1701 majority case. 1703 If the length of the Information Element is less than 255 bytes, the 1704 length is carried in the first byte of the Information Element. This 1705 is shown on Figure A. 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Length (< 255)| Information element | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | ... continuing as needed | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Figure A: Variable Length Information Element (length < 255 bytes) 1717 If the length of the Information Element is greater or equal than 1718 256 bytes, the first byte of the Information Element is 255, and the 1719 length is carried in the second and third bytes of the Information 1720 Element. This is shown in Figure B. 1722 0 1 2 3 1723 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 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | 255 | Length (256 to 65535) | IE | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | ... continuing as needed | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 Figure B: Variable Length Information Element 1731 (length 256 to 65535) bytes 1733 13. 1734 Template Management 1736 Flow Data records that correspond to a Template Record MAY appear in 1737 the same and/or subsequent IPFIX Messages. The Template Record is 1738 not necessarily carried in every IPFIX Message. As such, the 1739 Collecting Process MUST store the Template Record to interpret the 1740 corresponding Flow Data Records that are received in subsequent data 1741 messages. 1743 A Collecting Process that receives IPFIX Messages from several 1744 Observation Domains from the same Exporter MUST be aware that the 1745 uniqueness of the Template ID is not guaranteed across Observation 1746 Domains. 1748 The Template IDs must remain constant for the life of the Metering 1749 Process and the Exporting Process. If the Exporting Process or the 1750 Metering Process restarts for any reason, all information about 1751 Templates will be lost and new Template IDs will be created. 1752 Template IDs are thus not guaranteed to be consistent across an 1753 Exporting Process or Metering Process restart. 1755 A newly created Template record is assigned an unused Template ID 1756 from the Exporter. If the template configuration is changed, the 1757 current Template ID is abandoned and SHOULD NOT be reused until the 1758 Metering Process. If a Collecting Process should receive a new 1759 definition for an already existing Template ID, it MUST discard the 1760 previous template definition and use the new one. 1762 If a configured Template Record on the Exporting Process is deleted, 1763 and re-configured with exactly the same parameters, the same 1764 Template ID COULD be reused. 1766 The Exporting Process sends the Template FlowSet and Options 1767 Template FlowSet under the following conditions: 1769 1. After a Metering Process restarts, the Exporting Process MUST 1770 NOT send any Data FlowSet without sending the corresponding 1771 Template FlowSet and the required Options Template FlowSet in a 1772 previous message or including it in the same IPFIX Message. It 1773 MAY transmit the Template FlowSet and Options Template FlowSet, 1774 without any Data FlowSets, in advance to help ensure that the 1775 Collector will have the correct Template Record before receiving 1776 the first Flow or Options Data Record. 1778 2. In the event of configuration changes, the Exporting Process 1779 SHOULD send the new template definitions at an accelerated rate. 1780 In such a case, it MAY transmit the changed Template Record(s) 1781 and Options Template Record(s), without any data, in advance to 1782 help ensure that the Collector will have the correct template 1783 information before receiving the first data. 1785 3. On a regular basis, the Exporting Process MUST send all the 1786 Template Records and Options Template Records to refresh the 1787 Collecting Process. Template IDs have a limited lifetime at the 1788 Collecting Process and MUST be periodically refreshed. 1789 Two approaches are taken to make sure that Templates get 1790 refreshed at the Collecting Process: 1791 * Every N number of IPFIX Messages. 1792 * On a time basis, so every N number of minutes. 1793 Both options MUST be configurable by the user on the Exporting 1794 Porcess. 1795 When one of these expiry conditions is met, the Exporting 1796 Process MUST send the Template FlowSet and Options Template. 1798 14. 1799 The Collecting Process's Side 1801 The Collecting Process receives Template Records from the Exporting 1802 Process, normally before receiving Flow Data Records (or Options 1803 Data Records). The Flow Data Records (or Options Data Records) can 1804 then be decoded and stored locally on the devices. If the Template 1805 Records have not been received at the time Flow Data Records (or 1806 Options Data Records) are received, the Collecting Process SHOULD 1807 store the Flow Data Records (or Options Data Records) and decode 1808 them after the Template Records are received. A Collecting Process 1809 device MUST NOT assume that the Data FlowSet and the associated 1810 Template FlowSet (or Options Template FlowSet) are exported in the 1811 same IPFIX Message. 1813 The Collecting Process MUST NOT assume that one and only one 1814 Template FlowSet is present in an IPFIX Message. 1816 The life of a template at the Collecting Process is limited to a 1817 fixed refresh timeout. Templates not refreshed from the Exporting 1818 Process within the timeout are expired at the Collecting Process. 1819 The Collecting Process MUST NOT attempt to decode the Flow or 1820 Options Data Records with an expired Template. At any given time the 1821 Collecting Process SHOULD maintain the following for all the current 1822 Template Records and Options Template Records: 1824 Note that the Observation Domain is identified by the Source ID 1825 field from the IPFIX Message. 1827 Template IDs are unique per Exporting Process and per Observation 1828 Domain. 1830 If the Collecting Process receives a new Template Record (for 1831 example, in the case of an Exporter restart) it MUST immediately 1832 override the existing Template Record. 1834 The Collecting Process MUST note the Field ID of any Information 1835 Element that it does not understand and MAY discard the Information 1836 Element from the Flow Record. The Collecting Process MUST note the 1837 size and position of any Vendor Specified Information Element that 1838 it does not understand and discard the Information Element from the 1839 Flow Record. 1841 The Collector MUST accept padding in the Data FlowSet and Options 1842 Template FlowSet, which means for the Flow Data Records, the Options 1843 Data Records and the Template Records. 1844 Refer to the terminology summary table in Section 3.1. 1846 The IPFIX protocol has a sequence number field in the Export Header 1847 which increases with each IPFIX message. A Collector may detect out 1848 of sequence, dropped, or duplicate messages by tracking the sequence 1849 number. A collector SHOULD provide a logging mechanism for tracking 1850 out of sequence messages. Such out of sequence messages may be due 1851 to congestion on the network link between the Exporter and 1852 Collector, Collector resource exhaustion where it can not process 1853 the IPFIX messages at their arrival rate, Exporter resource 1854 exhaustion where it can not transmit messages at their creation 1855 rate, out of order packet reception, duplicate packet reception, an 1856 Exporting Process reset, or an attacker injecting false messages. 1858 15. 1859 Security Considerations 1861 Because IPFIX can be used to collect billing information and network 1862 forensics, confusing or blinding IPFIX must be seen as a prime 1863 objective during a sophisticated network attack. 1865 If an attacker is in a position to inject false messages into an 1866 IPFIX message stream this will allow them to send forged flow 1867 records, options, or templates. Forged templates may impair the 1868 Collectors ability to process any further Flow Records. Forged Flow 1869 Records would have a direct effect on the application using the 1870 Flows, for example a billing system may generate incorrect billing 1871 information. Forged options may be able to alter the meaning of flow 1872 records, for example if the sample rate is changed. 1874 The IPFIX messages themselves may contain information of value to an 1875 attacker, and thus care must be taken to confine their visibility to 1876 authorized users. 1878 IPFIX messages can be secured using IPsec. Alternatively if IPFIX 1879 runs on top of SCTP or TCP TLS [TLS] can be used. 1881 15.1 1882 IPsec Usage 1884 To secure messages between the Exporter and the Collector an IPFIX 1885 implementation MAY use IPsec. To ensure interworking between 1886 Exporters and Collectors from different vendors, the following IPsec 1887 profile MUST be supported. This profile is derived from [USEIPSEC]. 1889 15.1.1 Selectors 1891 IPFIX runs between manually configured pairs of hosts on the 1892 following transport ports (TBD). The appropriate selector would be 1893 Exporter-Collector pairs and port number. 1895 Note that, if the Exporter is a router, a non-interface ("loopback") 1896 address should be used. 1898 15.1.2 Mode 1900 IPsec MUST be run in transport mode. The AH and ESP MUST be 1901 supported by an IPFIX implementation of IPsec. 1903 The Authentication Header (AH) [RFC2402] MUST be used if 1904 authentication is required. The Security Protocol (ESP) [RFC2406] 1905 must be used if the is a threat to the IPFIX message content, or if 1906 it is confidential. 1908 Normally in situations where the ESP was required the AH would also 1909 be required. If ESP only is used, the sender's IP address MUST be 1910 checked against the IP address asserted in the key management 1911 exchange. 1913 15.1.3 Key Management 1915 In many networks, manual key management will be sufficient, and this 1916 reduces the complexity of the Exporter, albeit at a cost of greater 1917 configuration complexity. Manual key management MUST be supported. 1918 If a replay attack is considered likely, an automated key management 1919 the IKE [IKE] key management system SHOULD be used. 1921 15.1.4 Security Policy 1923 Connections should be accepted only from the designated peer. 1925 15.1.5 Authentication 1927 Given the number of IPFIX capable Exporters that are likely to be 1928 deployed by large ISPs, there will be circumstances where shared key 1929 mechanisms are not adequate. Where an automated key management 1930 system is used, certificate-based IKE SHOULD be supported. 1932 15.1.6 Availability 1934 It is accepted that IPsec will not be universally available in IPFIX 1935 Exporters, and that where it is available, there may be issues of 1936 throughput, which may itself raise security issues. In such 1937 circumstances the other security measures described in this draft 1938 provide some threat mitigation. 1940 15.2 1941 TLS Usage 1943 The IPFIX Exporter initiating a connection acts as a TLS client 1944 according to [TLS], and an IPFIX Collector that accepts a connection 1945 acts as a TLS server. If mutual authentication is required the IPFIX 1946 node acting as TLS server MUST request a certificate from the IPFIX 1947 node acting as TLS client, and the IPFIX node acting as TLS client 1948 MUST be prepared to supply a certificate on request. 1950 15.3 1951 Protection against DoS attacks 1953 An attacker may directly mount a DoS attack by generating large 1954 amounts of traffic. If TCP is used for transport, then the flow to 1955 the collector would back off due to congestion and eventually stall, 1956 blinding the IPFIX system. An attack could then proceed without 1957 further observation. SCTP-PR will have a different pathology under 1958 such an attack. Stale data at the head of the queue will get flushed 1959 giving some visibility of the attack. In case of UDP, IPFIX would 1960 reduce to some sort of sampling meaning that some forensics may be 1961 left. 1963 To avoid blinding of the IPFIX system some mechanism for service 1964 differentiation can be used to prioritizes IPFIX traffic over user 1965 traffic. An alternative is to use a dedicated network for the 1966 transport of IPFIX messages. By sending the IPFIX messages over a 1967 dedicated network, IPFIX message loss induced by user traffic 1968 congestion is minimized. However an attacker may trigger the 1969 generation of excessive IPFIX messages, and to avoid information 1970 loss during such an attack the IPFIX network must be adequately 1971 sized. 1973 15.4 1974 When IPsec or TLS is not an option 1976 The use of IPsec or TLS might not be an option because of 1977 performance issues. 1979 Without IPsec or TLS an IPFIX entity has no means to authenticate an 1980 IPFIX entity other than the Source IP address. Useful protection is 1981 gained by allocating Exporter and Collector IP addresses from ranges 1982 that are excluded from use by user traffic and preventing spoofing 1983 attacks by proper ingress filtering. Where large numbers of 1984 exporters, proxies and collectors are used in a network, it may be 1985 tempting for the administrator to not impose source IP address 1986 restrictions but this leaves a proxy or collector open to the 1987 reception of invalid information. Using an open proxy or collector 1988 is therefore to be deprecated. 1990 If IP address spoofing can not be prevented some level of protection 1991 against an insertion attack is required. With a modern 1992 implementation of TCP with good ISN randomization [XXX-REFERENCE] or 1993 SCTP insertion such attacks are difficult without the ability to 1994 snoop the packet flow [XXX-SCTP-BLIND-SPOOFING-REFERENCE]. UDP is 1995 vulnerable to insertion attacks however, randomization of the IPFIX 1996 sequence number might mitigate this problem. In all these cases, the 1997 sequence number space is relatively small giving only limited 1998 protection. Therefore a 64 bit cookie [L2TPv3] SHOULD be included as 1999 an element within all messages. 2001 The use of a dedicated network prevents IPFIX messages from being 2002 inspected by an attacker. 2004 15.5 2005 Logging an IPFIX Attack 2007 A Collector may detect problems by tracking the IPFIX sequence 2008 number and therefore SHOULD provide a logging mechanism for tracking 2009 out of sequence messages. [EDITOR�S NOTE: Double check whether this 2010 is already specified in an earlier section.] Such out of sequence 2011 messages may not only be caused by network congestion or 2012 Exporter/Collector resource exhaustion but also by an attacker 2013 injecting false messages. 2015 Note that an attacker may be able to exploit the behavior of the 2016 Collector when it receives an out of sequence message. For example 2017 a Collector that simply reset the expected sequence number upon 2018 receipt of a later message would easily be temporarily blinded by 2019 deliberately injecting messages with a much larger sequence number. 2021 [EDITOR�S NOTE: the security section may need be adapted to the 2022 revised transport section] 2024 16. 2025 IANA Considerations 2027 IANA will need to set up a registry of Flowset IDs, field types, 2028 scope and option codepoints. 2030 In compiling the registry of field types IANA must set asside a 2031 range value for vendor use. It is proposed that the range <0..32767> 2032 be administered by IANA for IETF defined IEs, and that the range 2033 <32768..65535> be allocated for private use by vendors. 2035 Similarly the scope and option codepoints need to be split between 2036 IANA administered and private ranges. 2038 17. 2039 Examples 2041 Let's consider the example of an IPFIX Message composed of a 2042 Template FlowSet, a Data FlowSet (which contains three Flow Data 2043 Records), an Options Template FlowSet and a Data FlowSet (which 2044 contains 2 Options Data Records). 2046 IPFIX Message: 2047 +--------+---------------------------------------------. . . 2048 | | +--------------+ +-----------------------+ 2049 |Message | | Template | | Data | 2050 | Header | | FlowSet | | FlowSet | . . . 2051 | | | (1 Template) | | (3 Flow Data Records) | 2052 | | +--------------+ +-----------------------+ 2053 +--------+---------------------------------------------. . . 2055 . . .+-------------------------------------------------+ 2056 +------------------+ +--------------------------+ | 2057 | Options | | Data | | 2058 . . .| Template FlowSet | | FlowSet | | 2059 | (1 Template) | | (2 Options Data Records) | | 2060 +------------------+ +--------------------------+ | 2061 . . .--------------------------------------------------+ 2063 17.1 2064 Message Header Example 2066 The Message Header is composed of: 2068 0 1 2 3 2069 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 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | Version = 0x000a | Length = 152 | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Export Time | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Sequence Number | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Source ID | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 17.2 2081 Template FlowSet Example 2083 We want to report the following Field Types: 2084 - The source IP address (IPv4), so the length is 4 2085 - The destination IP address (IPv4), so the length is 4 2086 - The next-hop IP address (IPv4), so the length is 4 2087 - The number of bytes of the Flow 2088 - The number of packets of the Flow 2090 Therefore, the Template FlowSet will be composed of the following: 2092 0 1 2 3 2093 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 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | FlowSet ID = 0 | Length = 28 bytes | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Template ID 256 | Field Count = 5 | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | IP_SRC_ADDR = 0x0008 | Field Length = 4 | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | IP_DST_ADDR = 0x000C | Field Length = 4 | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | IP_NEXT_HOP = 0x000F | Field Length = 4 | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | IN_PKTS = 0x0002 | Field Length = 4 | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | IN_BYTES = 0x0001 | Field Length = 4 | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 17.3 2111 Data FlowSet Example 2113 In this example, we report the following three Flow records: 2115 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Bytes 2116 | | | Number | Number 2117 --------------------------------------------------------------- 2118 198.168.1.12 | 10.5.12.254 | 192.168.1.1 | 5009 | 5344385 2119 192.168.1.27 | 10.5.12.23 | 192.168.1.1 | 748 | 388934 2120 192.168.1.56 | 10.5.12.65 | 192.168.1.1 | 5 | 6534 2121 0 1 2 3 2122 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 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | FlowSet ID = 256 | Length = 64 | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | 198.168.1.12 | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | 10.5.12.254 | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | 192.168.1.1 | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | 5009 | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | 5344385 | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | 192.168.1.27 | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | 10.5.12.23 | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | 192.168.1.1 | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | 748 | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | 388934 | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | 192.168.1.56 | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | 10.5.12.65 | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | 192.168.1.1 | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | 5 | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | 6534 | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 Note that padding was not necessary in this example. 2159 17.4 2160 Options Template FlowSet Example 2162 Per line card (the router being composed of two line cards), we want 2163 to report the following Field Types: 2165 - Total number of IPFIX Messages 2166 - Total number of exported Flows 2168 The format of the Options Template FlowSet is as follows: 2170 0 1 2 3 2171 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 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | FlowSet ID = 1 | Length = 24 | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Template ID 257 | Option Scope Length = 4 | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | Option Length = 8 | Scope 1 Field Type = 0x0003 | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | Scope 1 Field Length = 2 | TOTAL_EXP_PKTS_SENT = 41 | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | Field Length = 4 | TOTAL_FLOWS_EXP = 42 | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | Field Length = 4 | Padding | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 17.5 2187 Data FlowSet with Options Data Records Example 2189 In this example, we report the following two records: 2191 Line Card ID | IPFIX Message| Export Flow 2192 ------------------------------------------ 2193 Line Card 1 | 345 | 10201 2194 Line Card 2 | 690 | 20402 2196 0 1 2 3 2197 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 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | FlowSet ID = 257 | Length = 20 | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | 1 | 345 | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | 10201 | 2 | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | 2 | 690 | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | 20402 | Padding | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 18. 2211 References 2213 18.1 2214 Normative References 2216 [IPFIX-ARCH] Sadasivan, G, Brownlee, N. "Architecture Model for IP 2217 Flow Information Export" draft-ietf-ipfix-arch-02.txt", October 2003 2219 [IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information Model for 2220 IP Flow Information Export" draft-ietf-ipfix-info-02, November 2003 2222 [IPFIX-AS] Claise, B, Fullmer, M, Calato, P, Penno, R, "IPFIX 2223 Protocol Specifications", draft-ietf-ipfix-protocol-00.txt, June 2224 2003 2226 [UDP] Postel, J., "User Datagram Protocol" RFC 768, August 1980 2228 [TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM 2229 PROTOCOL SPECIFICATION" RFC 793, September 1981 2231 [RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol", 2232 RFC 2960, October 2000 2234 [PR-SCTP] Stewart, R, Ramalho, M, Xie, Q, Tuexen, M, Conrad, P. 2235 "SCTP Partial Reliability Extension", draft-ietf-tsvwg-prsctp- 2236 03.txt, January 2004 2238 18.2 2239 Informative References 2241 [IPFIX-REQ] Quittek, J, Zseby, T, Claise, B, Zander, S, 2242 "Requirements for IP Flow Information Export" draft-ietf-ipfix-reqs- 2243 15.txt, June 2003 2245 [IPFIX-AS] Zseby, T, Penno, R, Brownlee, N, Claise, B, "IPFIX 2246 Applicability", draft-ietf-ipfix-as-01.txt, October 2003 2248 [IPFIX-EVAL] Leinen, S, "Evaluation of Candidate Protocols for IP 2249 Flow Information Export (IPFIX)", draft-leinen-ipfix-eval-contrib- 2250 02.txt, January 2003 2252 [NETFLOW9] Claise, B, et al "Cisco Systems NetFlow Services Export 2253 Version 9", draft-claise-netflow-9-07.txt, December 2003 2255 [PEN] IANA Private Enterprise Numbers registry 2256 http://www.iana.org/assignments/enterprise-numbers 2258 [USEIPSEC] S. Bellovin, Guidelines for Mandating the Use of IPsec, 2259 draft-bellovin-useipsec-02.txt, October 2003, work 2260 in progress. 2262 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 2263 (IKE)", RFC 2409, November 1998. 2265 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 2266 1.0", RFC 2246, January 1999. 2268 [L2TPv3] J. Lau et al. Layer Two Tunneling Protocol (Version 3) 2269 draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, work 2270 in progress. 2272 [XXX-REFERENCE] 2274 [XXX-SCTP-BLIND-SPOOFING-REFERENCE] 2276 19. 2277 Acknowledgments 2279 We would like to thank the following persons for their valuable 2280 technical feedback: Juergen Quittek, Sebastian Zander, Dave Plonka, 2281 Jeff Meyer, Maurizio Molina, Carter Bullard, Randall Stewart, Peter 2282 Lei, Tal Givoly and many more. 2284 Authors Addresses 2286 Benoit Claise 2287 Cisco Systems 2288 De Kleetlaan 6a b1 2289 1831 Diegem 2290 Belgium 2291 Phone: +32 2 704 5622 2292 E-mail: bclaise@cisco.com 2294 Mark Fullmer 2295 OARnet 2296 2455 North Star Rd. 2298 Columbus, Ohio 43221 2299 Phone: +1 (614) 728-8100 2300 Email: maf@eng.oar.net 2302 Reinaldo Penno 2303 Nortel Networks 2304 2305 Mission College Blvd 2305 Santa Clara, CA 95054 2306 Phone: +1 408.565.3023 2307 Email: rpenno@nortelnetworks.com 2309 Paul Calato 2310 Riverstone Networks, Inc. 2311 5200 Great America Parkway 2312 Santa Clara, CA 95054 USA 2313 Phone: +1 (603) 557-6913 2314 Email: calato@riverstonenet.com 2316 Ganesh Sadasivan 2317 Cisco Systems, Inc. 2318 170 W. Tasman Dr. 2319 San Jose, CA 95134 2320 USA 2321 Phone: +1 (408) 527-0251 2322 Email: gsadasiv@cisco.com 2324 Stewart Bryant 2325 Cisco Systems, Inc. 2326 250, Longwater, 2327 Green Park, 2328 Reading, RG2 6GB, 2329 United Kingdom 2330 Phone: +44 (0)20 8824-8828 2331 Email: stbryant@cisco.com