idnits 2.17.1 draft-gsadasiv-ipfix-proposal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 100 has weird spacing: '... mostly subse...' == Line 415 has weird spacing: '...rmation to in...' == Line 633 has weird spacing: '...xported confi...' == Line 740 has weird spacing: '...ntifier that ...' == Line 844 has weird spacing: '...ntifier that ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8104 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-03) exists of draft-carpenter-midtax-01 ** Downref: Normative reference to an Informational draft: draft-carpenter-midtax (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '3') Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ganesh Sadasivan 3 Internet Draft Benoit Claise 4 Expiration Date: August 2002 cisco Systems, Inc. 5 February 2002 7 Proposal for IPFIX Flow Export Architecture and Data Model 9 draft-gsadasiv-ipfix-proposal-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo defines the architecture, the data model and the 35 information model for the export of measured IP flow information out 36 of an exporter to a collector, per the requirements defined in [1]. 37 While this document discusses the key concepts of flow export, some 38 of the topics discussed are far from complete. The intention of this 39 revision is to provide a starting framework for the flow export 40 architecture. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119. 48 Table of Contents 50 1 Introduction ........................................... 4 51 1.1 Overview ............................................... 4 52 1.2 Terminologies Used ..................................... 4 53 2 Flow Type and Flow Definition .......................... 5 54 2.1 Observation Point ...................................... 7 55 2.2 Unidirectional and Bidirectional Flows ................. 7 56 3 Metering Process Functions ............................. 7 57 3.1 Flow Classification .................................... 7 58 3.2 Selection Criteria Of Packets .......................... 8 59 3.2.1 Funtion on properties that determines a flow type (Fi) . 8 60 3.2.2 Sampling packets on a flow type (Si) ................... 8 61 3.3 Selection Criteria of flows for export ................. 8 62 3.4 Flow Expiration ........................................ 9 63 4 Flow Export Protocol ................................... 9 64 4.1 Simple Export Model .................................... 10 65 4.1.1 Collector Crash ........................................ 10 66 4.1.2 Collector Redundancy ................................... 10 67 4.1.3 Collector Failover ..................................... 10 68 4.2 Export Model with Reliable Control Connection .......... 10 69 4.2.1 Collector Crash ........................................ 11 70 4.2.2 Collector Redundancy ................................... 11 71 4.2.3 Collector Failover ..................................... 12 72 5 Flow Export Structure .................................. 12 73 5.1 Flow Header ............................................ 12 74 5.1.1 Fields ................................................. 13 75 5.2 Template and Template Flowsets ......................... 14 76 5.3 Categories of Template Flowset ......................... 14 77 5.3.1 Case A, Template for Flow Record Definition ............ 14 78 5.3.2 Case B, Template for Method Description ................ 16 79 5.3.3 Case C, Template for Dependancies ...................... 18 80 5.4 Template Export Management ............................. 21 81 5.5 Exporting exporter statistics and errors ............... 21 82 5.6 Exporting Flow Records ................................. 22 83 5.6.1 Field Descriptions ..................................... 22 84 6 Specific Technology Considerations ..................... 23 85 6.1 Network Address and Port Translation ................... 23 86 7 Information Model ...................................... 23 87 8 The Collector Side ..................................... 27 88 Acknowledgements ....................................... 28 89 References ............................................. 28 90 Authors' Addresses ..................................... 28 92 1. Introduction 94 1.1. Overview 96 The IP Flow data can be used for a variety of purposes. Usage-based 97 Accounting, Traffic Profiling, Traffic Engineering, Attack/Intrusion 98 Detection, Network Surveillance, QoS Monitoring are some of the 99 applications that use IP flows to list a few. Different applications 100 require different set of fields, which are mostly subsets of all the 101 fields that an IPFIX compliant exporter could possibly export. So 102 mostly not all possible exportable fields need to be exported at all 103 times. 105 The intention of the chosen approach here is to make the flow export: 107 1. Flexible: There should be flexibility in choosing to export only 108 the required fields. 110 2. Extensible: Addition of new fields or technologies should have 111 no impact on the export framework. 113 The transport protocol used for sending these flow records and 114 templates is beyond the scope of this document. 116 1.2. Terminologies Used 118 * Exporter: The entity on which flows are measured and are 119 exported. The exporter can be a router, a middlebox [2], or a 120 traffic measurement probe. 122 * Collector: The entity that collects the exported information. 124 * Observation Point: The observation point may be one or a set of 125 interfaces (physical or logical) of the exporter. 127 * Observation Domain: The set of observation points which is the 128 largest aggregatable set of flow information at the exporter is 129 termed as an observation domain. The observation domain presents 130 itself a unique ID to the collector for identifying the export 131 packets generated by it. 133 Example: The observation domian could be a router linecard, 134 composed of several interfaces with each interface being an 135 observation point. 137 * Metering Process: Measurement process that is carried out at the 138 observation domain. 140 * Flow Header: Every flow export packet includes a flow header 141 which carries some general information about the exporter, packet 142 identification etc. 144 * Flowset: Following the Flow Header, an export packet contains 145 information that would be parsed and interpreted by the collector 146 device. A flowset is a generic term for a collection of records 147 that follow the similar template format in an export packet. 149 * Flow Record: A flow record provides information about a specific 150 flow that was measured at an observation point using a certain 151 set of methods within an exporter. 153 2. Flow Type and Flow Definition 155 As defined in the requirement draft [1], 156 "A flow is a set of packets passing an observation point in the 157 network during a certain time interval. All packets belonging to a 158 particular flow have a set of common properties derived from the 159 data contained in the packet and from the packet treatment at the 160 observation point." 162 In this draft we define the flow more specifically. A flow is 163 defined as a set of packets passing an observation point in the 164 network during a certain time interval. All packets belonging to a 165 particular flow have a set of common properties. Each property is 166 defined as the result of applying a function to the values of: 168 a. one or more of packet header fields (eg. destination IP address) 169 b. one or more properties of the packet itself (eg. packet length) 170 c. one or more of fields derived from packet treatment (eg. AS 171 number) 173 A packet is defined to belong to a flow if it matches all the defined 174 properties of the flow. Flows can be defined in multiple ways. Some 175 examples are: 176 Example 1: 177 To create flows, we define the different fields to distinguish flows. 178 The different combination of the field values creates unique flows. 179 If the keys are defined as {source IP address, destination IP 180 address, TOS}, then all of 181 1. {192.1.40.1, 171.6.23.5, 4} 182 2. {192.1.40.23, 171.6.23.67, 4} 183 3. {192.1.40.23, 171.6.23.67, 2} 184 4. {198.20.9.200, 171.6.23.67, 4} 185 are different flows. 187 Example 2: 188 To create flows, we can apply a match function to all the packets 189 that pass through an observation point, in order to aggregate some 190 values. This could be done by defining the keys as {source IP 191 address, destination IP address, TOS} like in the example 1, and 192 applying the function which masks the least significant 8 bits of the 193 source IP address and destination IP address (.i.e the resultant is a 194 /24 address). The 4 flows from example 1 would now be aggregated 195 into 3 flows, by merging the flows 1. ans 2. into a single flow. 196 1. {192.1.40.0/24, 171.6.23.0/24, 4} 197 2. {192.1.40.0/24, 171.6.23.0/24, 2} 198 3. {198.20.9.0/24, 171.6.23.0/24, 4} 200 Example 3: 201 To create flows, we can filter some field values on all packets that 202 pass the observation point, in order to select only certain flows. 203 The filter is defined by choosing fixed values for specific fields 204 from the packet. 206 All the packets that go from a customer network 192.1.40.0/24 to 207 another customer network 171.6.23.0/24 with TOS value of 4 define a 208 flow. All other combinations don't define a flow and are not taken 209 into account. The 3 flows from example 2 would now be reduced to 1 210 flow, by filtering away the second and the third flow. 211 {192.1.40.0/24, 171.6.23.0/24, 4}. 213 The above example can be thought of as a function F takes as input 214 {source IP address, destination IP address, TOS}. The function 215 selects only the packets which satisfies all the 3 conditions which 216 are: 217 * mask the least significant 8 bits of source IP address, compare 218 against 192.1.40.0. 219 * mask the least significant 8 bits of destination IP address, 220 compare against 171.6.23.0. 221 * tos value equal to 4. 223 Depending on the values of {source IP address, destination IP 224 address, TOS} of the different observed packets, the metering process 225 function F would choose/filter/aggregate different sets of packets, 226 which would create different flows. In other words, based on various 227 combination of values of {source IP address, destination IP address, 228 TOS}, F(source IP address, destination IP address, TOS) would results 229 in the definition of one or more flows. The function F is referred to 230 as Flow Type. 232 2.1. Observation Point 234 For definition refer to section 1.2. A flow is uniquely defined by 235 the way it gets measured at an observation point. 236 Example: 237 The flow defined in the example 1 of section 2., can be used at 2 238 different observation points 'a' and 'b' in 2 different ways. 239 Observation point 'a' measures the packets that match the flow 240 {192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and 'b' 241 measures packets that match the same flow with a sampling rate of 1 242 in 100. 244 2.2. Unidirectional and Bidirectional Flows 246 A flow defined by the above terms is unidirectional. In case the 247 exporter has got the knowledge of the bi-directional flows and in 248 case the bi-directional information make sense, the exporter MAY 249 choose to export in the same Template/Flow Record, along with 250 bidirectional accounting information. This would save some bandwidth 251 as the exporter won't have to send two unidirectional flow records. 253 3. Metering Process Functions 255 3.1. Flow Classification 257 The collector MUST be able to map the flow to the corresponding 258 property types defined by the flow type. This can be done only if the 259 collector has a mapping from flow type identifier (carried in each 260 flow record) to its actual structure. More details of how this can be 261 acheived is decribed in section 5. 263 In addition the collecter, when it receives the flow records, MAY 264 need the following interpreting the flow records furthur: 266 a. Observation Point. 267 b. Selection Criteria of Packets 269 As mentioned in section 2.1, a flow record can be better analyzed if 270 the Observation Point from which it is measured is known. As such it 271 is recomended that the flow record carry the Observation Point 272 information along with the flow records when exported. In cases where 273 there is a single observation point or where the observation point 274 information is not relevant, the exporter MAY choose not to add this 275 to the flow records. 277 3.2. Selection Criteria Of Packets 279 The measurement device MAY define rules so that only certain packets 280 within a flow can be chosen for measurement at an observation point. 281 This MAY be done by one of the two types of methods defined below or 282 a combination of them. A combination of each of these ways can be 283 adopted to select the packets .i.e one can define a set of methods 284 {F1, S1, F2, S2, S3} executed in certain sequence at an observation 285 point to collect flows of a particular type. 287 3.2.1. Funtion on properties that determines a flow type (Fi) 289 Packets that satisfy a function on the fields defined by the packet 290 header fields or fields obtained while doing the packet processing or 291 the properties of the packet itself. 292 Example: 293 Mask/Match of the fields that define a filter. The filter may be 294 defined as {Protocol == TCP, Destination Port between 80 and 120}. 295 Multiple such filters could be used in any sequence to select 296 packets. 298 3.2.2. Sampling packets on a flow type (Si) 300 Packets that satisfy the sampling criteria for this flow type. 301 Example: 302 Sample every 100th packet that was received at an observation point 303 and collect the flow information for a particular flow type. Choosing 304 all the packets is a special case where sampling rate is 1:1. 306 3.3. Selection Criteria of flows for export 308 The measurement device MAY define additional rules so that only 309 certain flows records are picked up for export. This MAY be done by 310 either one of the two types of methods defined in 2.3.1 and 2.3.2 or 311 a combination of them. 313 Example: 314 The flow records which meets the following selection criteria are 315 only exported. 316 1. All flow records whose destination IP address matches 317 {20.3.1.5}. 318 2. Every other (.i.e sampling rate 1 in 2) flow record whose 319 destination IP address matches {160.0.1.30}. 321 3.4. Flow Expiration 323 A flow is considered to be inactive if no packets of this flow has 324 been observed at the observation point for a given timeout interval. 325 The flow can be exported under the following conditions: 327 1. If the exporter can deduce the end of a flow, the exporter 328 SHOULD export the flow records when the end of the flow is 329 detected. For example: flow generated by TCP type of traffic 330 where the FIN or RST bits indicate the end of the flow 332 2. If the flow has been inactive for a certain period of time. This 333 inactivity timeout SHOULD be configurable. For example: flow 334 generated by UDP type of traffic. 336 3. For long aging flows, the exporter SHOULD export the flow 337 records on regular basis, in order to: 338 1. report the flow records periodic accounting information to 339 the collector 340 2. avoid counter wrapping 341 This activity timeout SHOULD be configurable 343 4. If the exporter experiences resources constraints, a flow MAY be 344 prematurely expired (example: memory) 346 4. Flow Export Protocol 348 The information that needs to be exported from the exporter can be 349 classified into the following categories: 350 * Control Information - This includes the flow type definition, 351 selection criteria for packets within the flow. This is also 352 called as control stream. 353 * Flow record - This includes data records corresponding to the 354 various observed flows at each of the observation point. This is 355 also called as data stream. 357 4.1. Simple Export Model 359 If the network in which the exporter and collector are located 360 guarentees the security and reliability requirements, the transport 361 of the export flow packets MAY done over a light-weight transport 362 like UDP, for speed and simplicity. A single transport stream for 363 control and data would suffice here. 365 4.1.1. Collector Crash 367 In the simple export model, there is no way that a collector crash 368 can be detected. 370 4.1.2. Collector Redundancy 372 In case there are multiple collectors, the exporter MAY multicast the 373 flow records to the set of collectors that joined the export 374 multicast group, instead of sending several unicast streams towards 375 the different collectors. Multicast would lower the bandwidth 376 requirements on the export link in case that the collectors are on 377 the same media, and could lower the internal bus utilization on the 378 exporter. Using multicast session with more than one collector 379 joining the flow export multicast group, redundancy of collectors can 380 be easily achieved. 382 4.1.3. Collector Failover 384 In the simple export model, there is no way that a collector crash 385 can be detected. If the ability to detect collector crash is 386 required, a framework with some reliability built into it SHOULD be 387 chosen. This is explained below. 389 4.2. Export Model with Reliable Control Connection 391 If the network in which the exporter and collector are located does 392 not guarentee reliability, atleast the control information SHOULD be 393 exported over a reliable transport. There could be network security 394 concerns between exporter and collector. To avoid re-inventing the 395 wheel, and to reduce the complexity of flow export protocol, one or a 396 combination of the following methods MAY be adopted as a solution to 397 achieve security : 399 * IP Authentication Header MAY be used when the threat environment 400 requires stronger integrity protections, but does not require 401 confidentiality. 402 * IP Encapsulating Security Payload (ESP) MAY be used to provide 403 confidentiality and integrity. 404 * If the transport protocol used is TCP, optionally TCP MD5 405 signature option MAY be used to protect against spoofed TCP 406 segments. 408 The flow records MAY be exported over an unreliable or reliable 409 transport protocol. 411 As explained above the transport connection (in the case of a 412 connection oriented protocol) is pre-setup between the exporter and 413 the collector and is out of the scope of this document. Once 414 connected, the collector side receives the control information and 415 uses this information to interpret the flow records. The exporter 416 SHOULD set the keepalive (in the case of TCP) or the HEARTBEAT 417 interval in the case of SCTP to a sufficiently low value so that it 418 can quickly detect a collector crash. On detecting a Keepalive 419 timeout, the exporter SHOULD stop sending the flow export data to the 420 collector and try reconnecting the transport connection. This is 421 valid for a single collector scenario. The case of multiple collector 422 is discussed in section 4.2.2. 424 4.2.1. Collector Crash 426 The collector crash is detected at the exporter by the break in 427 control connection (depending on the transport protocol the 428 connection timeout mechanisms differ). On detecting loss of 429 connectivity, the exporter retries to open the control connection 430 with the collector. 432 4.2.2. Collector Redundancy 434 The control information is exported through a reliable transport and 435 so cannot be multicast. The data stream MAY be multicast if it is 436 over an unreliable transport like UDP. But the collector SHOULD join 437 the multicast group only after the control stream is established and 438 it has received the control information from the exporter. Using 439 multicast session with more than one collector joining the flow 440 export multicast group, redundancy of collectors can be easily 441 achieved. 443 4.2.3. Collector Failover 445 This is an extension to section 4.2 to take care of collector crash. 446 The exporter opens control connections to multiple collectors. But 447 data gets sent only to one of the collectors which is chosen as the 448 primary. There could be one or more collectors configured as 449 secondary and a priority assigned to them. The primary collector 450 crash is detected at the exporter by the break in control connection 451 (depending on the transport protocol the connection timeout 452 mechanisms differ). On detecting loss of connectivity, the exporter 453 opens data stream with the secondary collector of the next highest 454 priority. This collector now becomes the primary. The maximum export 455 data loss would be the amount of data exported in the time between 456 when the loss of connectivity to the collector happened, and the time 457 at which this was detected by the exporter. 459 5. Flow Export Structure 461 The general format of flow export packet is as follows: 463 +-------+-------------------------------------------------------+ 464 |Flow | +----------------+ +---------------+ +--------------+ | 465 |Header | | Flow Set | | Flow Set | | Flow set | | 466 | | +----------------+ +---------------+ +--------------+ | 467 +-------+-------------------------------------------------------+ 469 5.1. Flow Header 471 The flow header contains the export packet level information and some 472 information pertaining to the exporter itself. The flow header format 473 is as follows: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Version Number | Flags | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | sysUpTime | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Unix Secs | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Sequence Number | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Source ID | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 5.1.1. Fields 491 Version Number: 492 The version number of the flow export protocol on the exporter side. 493 Both control and data records exported from the exporter are self- 494 describing. The collector can thus selectively choose to collect the 495 information from the export records regardless of the version. Note 496 that the packet header format has been kept similar the one developed 497 by the different versions of Netflow defined by Cisco Systems, for 498 backward compatibility. This is also the reason why the version field 499 is currently 0x0009. 501 Flags: 502 Flags indicate the packet type and other attributes associated with 503 the packet. The format of flags is as follows: 505 15 1 0 506 +----------------------------------------------------+--------+ 507 | |Control/| 508 | Reserved |Data / | 509 | |Both | 510 +----------------------------------------------------+--------+ 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Version Number | Flags |*|*| 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 ** Control/Data/Both 520 Control/Data/Both: 521 Flag to indicate whether the export packet is control/data/both. 522 When separate data stream is used, the exporter MUST set the flags to 523 indicate whether the stream type is control and data. 525 SysUpTime: 526 Time in milliseconds since this device was first booted. 528 Unix Secs: 529 Seconds since 0000 UTC 1970 531 Sequence Number: 532 Exporter generated number which uniquely identifies a packet. The 533 sequence number increments for subsequent export packets. A separate 534 sequence number is manintained for control and export data packets if 535 control and data are send in separate packets. 537 Source ID: 538 Unique identifier per observation domain. 540 5.2. Template and Template Flowsets 542 Templates are used to completely identify the structure and semantics 543 of a particular information that needs to be communicated from the 544 exporter to the collector. Each template is uniquely identified by a 545 Template ID. The Template ID is a 16 bit identifier. A block of 546 templates from <0-255> are reserved for sending some of the control 547 information. The rest of the template IDs can be used by the 548 exporter to define the templates for the various flow types defined 549 within the exporter. A Template within an export packet is called as 550 a template record. A Template Flowset is a collection of one or more 551 template records which have been grouped together in an export 552 packet. The Flowset ID of a template flowset maps to a particular 553 template format. 555 5.3. Categories of Template Flowset 557 As explained in the terminology section, a flowset is a collection of 558 records with a similar template format in an export packet. Flowset 559 ID shares the same number space as a template ID. Template ID <0-255> 560 are reserved as mentioned above and these are used by Flowset IDs to 561 send Template Flowsets of different formats. All of the Templates are 562 sent over the control stream. The different template formats being 563 used are: 565 5.3.1. Case A, Template for Flow Record Definition 567 The common examples of this case are templates for exported flow 568 records, and templates for flow related statistics or errors in the 569 exporter. Example of statistics information: total numbers of flows. 570 The format of the Template Flowset for this case is described below: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | FlowSet ID = 0 | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Template ID 1 | Field Count | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Field Type 1 | Field Length 1 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Field Type 2 | Field Length 2 | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | ... | ... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Field Type N | Field Length N | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Template ID 2 | Field Count | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Field Type 1 | Field Length 1 | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Field Type 2 | Field Length 2 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | ... | ... | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Field Type M | Field Length M | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 FlowSet ID: 599 Template flowset of this structure has a FlowSet ID of 0. 601 Length: 602 Total length of this FlowSet including the Flowset ID and the Length 603 field itself. Since an individual Template FlowSet MAY contain 604 multiple Template IDs (as illustrated above), the Length value will 605 be used to determine the position of the next FlowSet. 607 Template ID: 608 A unique ID per observation domain that defines the type of the 609 record. Template IDs 0-255 are reserved for special uses.Templates 610 that define Flow Record formats begin numbering at 256. 612 Field Count: 613 Number of fields in this Template Record. Since a Template Flowset 614 MAY contain multiple Template Records, this field allows the 615 collector to determine the end of the current Template Record and the 616 start of the next. 618 Field Type: 619 A numeric value that represents the type of the field. The possible 620 values of this field are described in the information model section. 622 Field Length: 623 The length of the above defined field, in bytes. See the information 624 model section for the field length. 626 Note that the reason why we need the Field Length, even if this one 627 is fixed in the Information Model is because a collector MUST be able 628 to decode flow records, even if it doesn't know the semantics of 629 certain field types within the flow records. 631 5.3.2. Case B, Template for Method Description 633 This case describes the format for exported configuration 634 information. Each of the configuration templates within this flowset 635 describes : 637 * List of methods that define the Selection Criteria and the 638 parameters for each method. 639 * Observation Point and its description. 641 One thing to note here is that instead of template ID, each 642 configuration template is associated with an Observation ID. The 643 observation ID uniquely identifies a {, Observation 644 Point}. At the same Observation point, multiple methods could be 645 adopted for packet measurement. As mentioned in section 3.1, for the 646 full interpretation of the flows from a metering process, the 647 associated {, Observation Point} associated with each 648 flow record is required. This can be achieved by sending Observation 649 ID as one of the fields in each of the flow records. In such a case 650 the template for flow records (see section 5.3.1) would define 651 Observation ID as one of the field types. 652 Example: 653 The exporter could be collecting the IPV4 packets that pass through 654 an observation point at a sampling rate of 1 in 100 while the IPV6 655 packets that pass through the same observation point are collected at 656 a sampling rate of 1 in 200. The number space of Observation ID is 657 different from that of the Template ID. Each time a configuration 658 change happens w.r.t {, Observation Point}, a new 659 Observation ID is generated. The rate of configuration changes within 660 an exporter could range from very infrequent to very frequent. To 661 take care of the frequent cases, Observation ID is assigned a 32-bit 662 quantity. 664 The following diagram shows the Template format. 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | FlowSet ID = 1 | Length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Observation ID 1 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Method Count | Reserved | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Method Id 1 | Parameter Count | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Parameter Type 1 | Parameter Length 1 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Parameter Value (Padded to nearest 4 bytes) | 680 ~ ~ 681 | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | ... | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Parameter Type K | Parameter Length K | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Parameter Value (Padded to nearest 4 bytes) | 688 ~ ~ 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Method Id 2 | Parameter Count | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | ... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Observation Point ID | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Sub-element Count | Sub-element Type 1 | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Sub-element Length 1 | Sub-element Value 1 (Padded | 700 | | to nearest 2 bytes) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | ... | ... | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Sub-element Length M | Sub-element Value M (Padded | 705 | | to nearest 2 bytes) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Observation ID 2 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Method Count | Reserved | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | ... | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 FlowSet ID: 715 Template flowset of this structure has a FlowSet ID of 1. 717 Length: 718 Total length of this FlowSet including the Flowset ID and Length 719 field. 721 Observation ID: 722 32 bit identifier per {, Observation Point} tuple. 724 Method Count: 725 Number of methods used for selecting the packet. 727 Parameter Count: 728 The number of parameters for this method. 730 Parameter Type: 731 Type of the Parameter used by this method. 733 Parameter Length: 734 Length of the Parameter used by Parameter Type. 736 Parameter Value: 737 Configured value of the parameter Parameter Type. 739 Observation Point ID: 740 32 bit identifier that defines an observation point. 742 Sub-element Count: 743 Number of sub-elements that form the observation point. 745 Sub-element Type: 746 Type of one sub-element. 748 Sub-element Length: 749 Length of one sub-element represented by Sub-element Type. 751 Sub-element Value 752 Value of the sub-element of type Sub-element Type. 754 5.3.3. Case C, Template for Dependancies 756 If multiple methods are used in conjunction on the observation point, 757 in order to analyze the flow records, the collector SHOULD know the 758 dependancy between the multiple methods used. At the same observation 759 point, multiple different sets of measurement could be carried out 760 simultaneously or independently to the packets. Depending on how 761 these sets of measurements are done, the interpretation of flow 762 records vary. 764 Example : 765 Say packets passing through an observation point are filtered, using 766 2 different filters. 768 case 1: 769 Filters are completely non-overlapping. Say the filters are set on 770 the destination IP prefix. The first filter F1 masks and matches the 771 destination prefix {1.0.0.0/8} and the second filter masks and 772 matches the destination prefix {2.0.0.0/8}. The result of applying 773 these 2 filters generates 2 different sets of flows which are 774 completly non-overlapping. The collector could sum up the counters of 775 flows that result from F1 and F2 to provide more aggregation. 777 case 2: 778 Overlapping which are predictable. Say one filter is set on the 779 source IP prefix and destination IP prefix and the other on the 780 destination IP address. The first filter F1 masks and matches the 781 {source prefix = 1.0.0.0/8, destination prefix = 2.0.0.0/8} and the 782 second filter F2 masks and matches {destination prefix = 2.0.0.0/8}. 783 Whenever a packet matches F1 it will necessarily match F2 also. The 784 result is 2 different sets of flows where the flows created by 785 applying F1 is a subset of that created by F2. 787 case 3: 788 Overlapping which are un-predictable. Say the filters are set on the 789 source IP prefix and destination IP prefix. The first filter F1 masks 790 and matches the {source prefix = 1.0.0.0/8, destination prefix = 791 2.2.0.0/16} and the second filter F2 masks and matches {source prefix 792 = 1.1.0.0/16, destination prefix = 2.0.0.0/8}. A packet with {source 793 IP address = 1.2.3.4, destination IP address = 2.2.2.2} matches F1 794 but not F2. A packet with {source IP address = 1.1.3.4, destination 795 IP address = 2.3.1.1} matches F2 and not F1. The result of applying 796 these 2 filters generates 2 different sets of flows, the dependancy 797 between the two being unpredictable. 799 Discovering the dependancies amongst the different methods at the 800 observation point is non-trivial job for the exporter. The exporter 801 will deduce the dependancies to the best of its capability and inform 802 the collector. If unknown, the dependancy relationship will be set to 803 unpredictible. The exporter MAY implement and export this dependancy 804 template. 806 The format of the dependency template template is as follows. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | FlowSet ID = 2 | Length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Number Of Dependency | Reserved | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Dependency 1 | Number Of Observation IDs | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Dependency ID 1 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Observation Id 1 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Observation Id 2 | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | ... | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Dependency 2 | Number Of Observation IDs | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Dependency ID 2 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Observation Id 1 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Observation Id 2 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | ... | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 FlowSet ID: 837 Template flowset of this structure has a FlowSet ID of 2. 839 Length: 840 Total length of this FlowSet including the Flowset ID and Length 841 field. 843 Observation Point ID: 844 32 bit identifier that defines an observation point. 846 Number Of Dependency: 847 Number of dependency for this observation point. 849 Dependency: 850 Tells whether the set of templates that follow are dependent, 851 independent or unpredictible. As mentioned in section 5.3.2, {, observation point} is identified by the Observation ID. 854 Number Of Observation IDs: 855 Number of Observation IDs in the dependency set. 857 Dependency ID: 858 Each dependency set is identified by a 32 bit ID. 860 Observation ID: 861 An element of an dependent or independent set. 863 5.4. Template Export Management 865 The exporter takes the following steps for template export: 867 * Periodically sends the entire template information and 868 configuration information to the collector. This corresponds to 869 the set of all Template IDs along with their descriptions and the 870 set of all Observation IDs along with their descriptions. The 871 periodic export frequency SHOULD be configurable in the exporter. 872 * Changes in the control information happens due to change in 873 configuration or change in the templates of export flow records. 874 These changes can affect one or more of: 875 1. Template of flow records. See 4.3.1 876 2. Templates of configuration information. See 4.3.2 877 3. Dependency templates. See 4.3.3 879 When the control information changes, only the set of differences 880 in the information at the granularity of a template need to be 881 exported to the collector. This is valid for case 1. and case 2. 883 For case 1., a new Template ID is generated and the changed 884 template along with its description is sent to the collector. For 885 case 2., a new Observation ID is generated and the changed 886 Observation ID along with its description is sent to the 887 collector. Case 2 may result in case 3 also. For case 3., the 888 entire set of dependency list is regnerated at the exporter and 889 sent to the collector. The set of differences MAY be sent a 890 configurable number of consecutive times. This configurable 891 parameter is recommended to be more than one in the case of the 892 simple export model. 894 5.5. Exporting exporter statistics and errors 896 The statistics and errors from the exporter MAY be periodically 897 exported to the collector. The information model specifics for 898 statistics and errors will be defined in future phase. 900 5.6. Exporting Flow Records 902 As mentioned above flow records can go through the same stream as a 903 control information or through a different stream as per the 904 description in section 4.1 and 4.2. If data stream is different, it 905 would be identified by a different sequence number. In anycase the 906 flags field of the flow export header MUST indicate that the packet 907 has only data flowsets (flag in the flow export header is set to 908 "data") or if it carries control and data flowsets (flag is set to 909 "both"). Data packets contain flow records corresponding to one or 910 more template IDs. Flow records that belong to the same template ID 911 can be grouped together to utilize the bandwidth better. A 912 collection of one or more flow records that have have the same 913 template ID is termed as a Data Flowset. The Flowset ID of a data 914 flowset is assigned the Template ID to which all the records in this 915 data flowset belong to. The collector uses this Flowset ID to 916 interpret the data contained within the flow records. A data flowset 917 cannot be split across multiple flow record packets. 919 The format of the Data Flowset is described below: 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | FlowSet ID = Template ID | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Record 1 - Field Value 3 | ... | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Record 2 - Field Value 3 | ... | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Record 3 - Field Value 1 | ... | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 5.6.1. Field Descriptions 939 FlowSet ID = Template ID 940 Template ID corresponding to the flow records in the flowset. 942 Length: 943 The length of the Data FlowSet including FlowSet ID and the Length . 945 Record N - Field N 946 The remainder of the Data FlowSet is a collection of field values. 948 The Type and Length of the fields have been previously defined in the 949 Template Record referenced by the FlowSet ID/Template ID. 951 The flow records contains the values for the fields defined by flow 952 type. 954 6. Specific Technology Considerations 956 6.1. Network Address and Port Translation 958 In case the exporter is doing NAT [3] and in case the observation 959 domain has got the knowledge of both inside and outside parameters, 960 the exporter MAY choose to export both inside and outside parameters 961 in the same Template/Flow Record (The NAT parameters being the IP 962 address and/or the UDP/TCP ports). If not the exporter will only 963 export the parameters observed at the observation point. 965 This just implies that the information model MUST have inside and 966 outside parameters defined. 968 A NAT device can be installed between the exporter and the collector. 969 This means that the flow records IP address could be meaningless for 970 the data analyzis without a NAT translator on the collector's side. 971 This case is out of the scope of this document as it concerns the 972 analysis of the data and not the export. 974 7. Information Model 976 The information model for a flow measurement report is the list of 977 possible attributes of a flow, selection criteria (like parameters 978 for sampling) and observation point. The table below described all 979 the field type definition that an IPFIX compliant exporter will 980 support: 982 Field Type Value Length Description 984 IN_BYTES_32 1 4 32-bit counter for bytes 985 associated with an IP Flow 987 IN_PKTS_32 2 4 32-bit counter for packets 988 associated with an IP Flow 990 FLOWS 3 4 Number of main cache flows 991 that were aggregated 993 PROT 4 1 IP protocol byte. 995 TOS 5 1 Type of service byte 997 TCP_FLAGS 6 1 TCP Flags (cumulative OR 998 of TCP flags) 1000 TCP/UDP source port 1001 L4_SRC_PORT 7 2 number (.e.g, FTP, Telnet, 1002 etc...) 1004 IPV4_SRC_ADDR 8 4 Source IPv4 Address 1006 SRC_MASK 9 1 source route's mask bits 1008 INPUT_SNMP 10 2 Input interface index 1010 TCP/UDP destination port 1011 L4_DST_PORT 11 2 number (.e.g, FTP, Telnet, 1012 etc...) 1014 IPV4_DST_ADDR 12 4 Destination IPv4 Address 1016 DST_MASK 13 1 destination route's mask 1017 Bits 1019 OUTPUT_SNMP 14 2 Output interface index 1021 IPV4_NEXT_HOP 15 4 Next hop router's IPv4 1022 Address 1024 SRC_AS 16 4 Source BGP Autonomous 1025 System Number 1027 DST_AS 17 4 Destination BGP Autonomous 1028 System Number 1030 BGP_NEXT_HOP 18 4 Next-hop router in the BGP 1031 domain 1033 IPM_DPKTS 19 4 Packet count for IP 1034 Multicast 1036 IPM_DOCTETS 20 4 Octet (byte) count for IP 1037 Multicast 1039 SysUptime at which the 1040 LAST_SWITCHED 21 4 last packet of this flow 1041 was switched 1042 SysUptime at which the 1043 FIRST_SWITCHED 22 4 first packet of this flow 1044 was switched 1046 IN_BYTES_64 23 8 64-bit counter for bytes 1047 associated with an IP Flow 1049 IN_PKTS_64 24 8 64-bit counter for packets 1050 associated with an IP Flow 1052 MAC_ADDR 25 6 Layer 2 Media Access 1053 Control address associated 1054 with a flow 1056 VLAN_ID 26 2 Virtual LAN identifier 1057 associated with a flow 1059 IPV6_SRC_ADDR 27 16 IPv6 Source Address 1061 IPV6_DST_ADDR 28 16 IPv6 Destination Address 1063 IPV6_SRC_MASK 29 1 IPv6 Source Mask 1065 IPV6_DST_MASK 30 1 IPv6 Destination Mask 1067 FLOW_LABEL 31 2 IPV6 Flow Label 1069 ICMP Packet Type. This is 1070 ICMP_TYPE 32 1 reported as (ICMP Type * 1071 256) + ICMP code 1073 IGMP_TYPE 33 1 IGMP Packet Type 1075 When using Sampling, 1076 the rate at which 1077 packets are sampled. For 1078 SAMPLING_INTERVAL 34 1 example, a value of 100 1079 indicates that one of 1080 every hundred packets is 1081 sampled. 1083 The type of algorithm used 1084 for sampling data. 1085 Currently, the only 1086 sampling algorithm defined 1087 SAMPLING_ALGO 35 1 is: 1088 0x02 packet-sampling 1089 Timeout value for active 1090 FLOW_ACTIVE_TIMEOUT 36 2 flow entries in the 1091 cache. 1093 Timeout value for inactive 1094 FLOW_INACTIVE_TIMEOUT 37 2 flow entries in the 1095 cache. 1097 OUT_BYTES_32 38 4 32-bit counter for bytes 1098 associated with an IP Flow 1100 OUT_PKTS_32 39 4 32-bit counter for packets 1101 associated with an IP Flow 1103 OUT_BYTES_64 40 8 64-bit counter for bytes 1104 associated with an IP Flow 1106 OUT_PKTS_64 41 8 64-bit counter for packets 1107 associated with an IP Flow 1108 inside TCP/UDP destination 1110 INSIDE_L4_SRC 42 2 port number (.e.g, FTP, 1111 Telnet, etc...) 1112 only applicable with NAT 1114 INSIDE_IPV4_SRC_ADDR 43 4 Source IPv4 Address 1115 only applicable with NAT 1117 TCP/UDP destination port 1118 INSIDE_L4_DST_PORT 44 2 number (.e.g, FTP, telnet 1119 etc...) 1120 only applicable with NAT 1122 INSIDE_IPV4_DST_ADDR 45 4 Destination IPv4 Address 1123 only applicable with NAT 1125 INSIDE_IPV6_SRC_ADDR 46 16 IPv6 Source Address 1126 only applicable with NAT 1128 INSIDE_IPV6_DST_ADDR 47 16 IPv6 Destination Address 1129 only applicable with NAT 1131 TCP/UDP destination port 1132 OUTSIDE_L4_SRC_PORT 48 2 number (.e.g, FTP, Telnet, 1133 etc...) 1134 only applicable with NAT 1136 OUTSIDE_IPV4_SRC_ADDR 49 4 Source IPv4 Address 1137 only applicable with NAT 1138 TCP/UDP destination port 1139 OUTSIDE_L4_DST_PORT 50 2 number (.e.g, FTP, Telnet, 1140 etc...) 1141 only applicable with NAT 1143 OUTSIDE_IPV4_DST_ADDR 51 4 Destination IPv4 Address 1144 only applicable with NAT 1146 OUTSIDE_IPV6_SRC_ADDR 52 16 IPv6 Source Address 1147 only applicable with NAT 1149 OUTSIDE_IPV6_DST_ADDR 53 16 IPv6 Destination Address 1150 only applicable with NAT 1152 Flow Direction 54 1 The direction of the flow 1153 observed at the 1154 observation point. If the 1155 observation point is a set 1156 of interface(s) the 1157 direction is w.r.t the 1158 wire. 1160 The "Value" column in the above table is a numeric identifier for the 1161 field type. 1163 When extensibility is needed (when new technologies are defined or 1164 when some new field types are needed), the newly added field types 1165 MUST be added to the list. They MUST be defined by the exporter and 1166 understood by the collector. 1168 8. The Collector Side 1170 The collector SHOULD receive template definitions from the exporter, 1171 before receiving flow records. The flow records can then be decoded 1172 and stored locally on the collector. In case the template definitions 1173 have not been received at the time a Flow Record is received, the 1174 collector SHOULD keep the Flow Record for later decoding when the 1175 template definitions will be received. The collector MUST decode and 1176 store the entire flow records, even if the semantics of one or more 1177 of the field types in the template associated with the flow record is 1178 not understood. 1180 The collector SHOULD maintain a table of active templates. The 1181 template information SHOULD be kept for templates of flow records, 1182 non-flow records, and dependency template. The table format is as 1183 defined below. 1185 +-----------+--------------+--------------+-----------------+ 1186 | Exporter | Template ID | Template Def |Time Since Last | 1187 | | | |Refresh (Tr) | 1188 +-----------+--------------+--------------+-----------------+ 1190 Note that the Template IDs are unique per exporter. A template can 1191 exist without being refreshed by an update for Tm period of time. Tr 1192 gets incremented periodically. Each time an update is received for a 1193 template, Tr is reset to 0. When Tr >= Tm, the entry is removed from 1194 the table. 1196 Collector devices SHOULD use the combination of the source IP address 1197 and the Source ID field to distinguish different export streams 1198 originating from the same exporting device. For example: different 1199 linecards on a router MAY generate different export streams to a 1200 single collector. 1202 Acknowledgements 1204 We like to thank Will Eatherton, Michelle Ma, Peram Marimuthu, Martin 1205 Djernaes and Vamsi Valluri for reviewing this document and providing 1206 valuable comments. 1208 References 1210 [1] Requirements for IP Flow Export, 1211 1213 [2] B. Carpenter, "Middleboxes: taxonomy and issues", draft- 1214 carpenter-midtax-01.txt, work in progress. 1216 [3] RFC 3022, Traditional IP Network Address Translator (Traditional 1217 NAT) 1219 Authors' Addresses 1221 Ganesh Sadasivan 1222 Cisco Systems, Inc. 1223 170 W. Tasman Dr. 1224 San Jose, CA 95134 1225 USA 1226 Phone: +1 (408) 527-0251 1227 Email: gsadasiv@cisco.com 1228 Benoit Claise 1229 Cisco Systems 1230 De Kleetlaan 6a b1 1231 1831 Diegem 1232 Belgium 1233 Phone: +32 2 704 5622 1234 Email: bclaise@cisco.com