idnits 2.17.1 draft-sommer-ipfix-mediator-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 6009 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-05) exists of draft-dressler-ipfix-aggregation-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Sommer 3 Internet-Draft F. Dressler 4 Expires: May 15, 2008 Univ. Erlangen 5 G. Muenz 6 Univ. Tuebingen 7 November 12, 2007 9 Mediator-Specific Extensions to IPFIX Protocol and Information Model 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 15, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 IPFIX supports the concept of an Mediator, a device that receives, 44 transforms, and exports data streams using IPFIX. One of the most 45 important requirements is the reduction of the volume of IPFIX 46 traffic by discarding and aggregating received information. This 47 document introduces a number of extensions to the IPFIX Protocol and 48 IPFIX Information Model that support the export of aggregated IPFIX 49 data. In particular, techniques are introduced that optimize the 50 transport of descriptive information. Thus, more information can be 51 preserved in the transmission while further reducing both the number 52 and the size of IPFIX messages. All the proposed extensions are 53 directly applicable to the IPFIX Mediator but can be used in many 54 different applications as well. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Rich Template . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Abstract data type ipv4Network . . . . . . . . . . . . . . . . 10 62 5. Abstract data type portRanges . . . . . . . . . . . . . . . . 10 63 6. excludedPropertiesId Information Element . . . . . . . . . . . 11 64 7. precedingRulePropertiesId Information Element . . . . . . . . 13 65 8. Security considerations . . . . . . . . . . . . . . . . . . . 14 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 69 10.2. Informative References . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 17 73 1. Introduction 75 The IPFIX Mediator is intended to provide techniques and features to 76 process IPFIX data in a Mediation Process. This process receives 77 data streams using IPFIX. It can apply transformations or 78 aggregation techniques and forward the resulting Flow information to 79 an Exporting Process and, thus, to another IPFIX collector. Flow 80 aggregation is one of the most challenging and important operations 81 in high-bandwidth networks. The main idea is to reduce both the 82 number and the size of IPFIX messages. This document introduces 83 extensions to the IPFIX Protocol and IPFIX Information Model that 84 support the export of aggregated IPFIX data. In particular, a new 85 Template type is introduced and additional Information Elements are 86 described. All these extensions allow and optimize the transport of 87 descriptive information on aggregated IPFIX data. Thus, more 88 information can be preserved in the transmission while further 89 reducing both the number and the size of IPFIX messages. All the 90 proposed extensions are directly applicable to the IPFIX Mediator but 91 can be used in many different applications as well. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 96 Illustrations of abstract data types are written in Augmented Backus- 97 Naur Form (ABNF), as specified in [RFC4234], extending the abstract 98 data types defined in [I-D.ietf-ipfix-info]. 100 2. Terminology 102 Apart from the basic terms as defined in [I-D.ietf-ipfix-protocol], 103 the following terms are used within this document: 105 Compound Flow: 106 A Compound Flow is the result of an aggregation of one or more 107 individual input Flows that matched an Aggregation Rule. It 108 might, for example, contain the total count of all packets 109 addressed to a common subnet that were observed within a given 110 time interval. 112 Aggregation Rule: 113 An Aggregation Rule defines the properties of a Compound Flow and 114 the contents of the corresponding Flow Records. Optionally, a set 115 of filtering criteria MAY be specified in order to restrict the 116 applicability of the rule to those Flows that show certain 117 patterns. 119 3. Rich Template 121 [I-D.dressler-ipfix-aggregation] describes how pattern matching is 122 used to restrict the applicability of an Aggregation Rule and how 123 patterns define Common Properties of the resulting Compound Flows. 124 In order to avoid the overhead of the repeated transmissions of all 125 Common Properties (or their identifiers) in all Flow Records, a new 126 Template Set, the "Rich Template Set" is introduced. This Template 127 Set allows an Exporting Process to simultaneously declare and 128 transmit Common Properties to a receiver. 130 The basic format of a Rich Template Set is shown in Figure 1. It is 131 the same as that of a Template Set defined in 132 [I-D.ietf-ipfix-protocol], except for a different Set ID. The format 133 of individual Rich Template Records, however, differs from that of 134 Template Records and is shown in Figure 2. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Set ID = 4 | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | Rich Template Record 1 | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 | ... | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | | 150 | Rich Template Record N | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Padding (opt) | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Figure 1: Rich Template Set Format 158 The Rich Template Set field definitions are as follows: 160 Set ID 161 Type of this Template Set. A Set ID value of 4 is proposed for the 162 Rich Template Set. 164 Length 165 Total length of this set in bytes, as defined in 166 [I-D.ietf-ipfix-protocol]. 168 Padding 169 OPTIONAL padding, as defined in [I-D.ietf-ipfix-protocol]. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Template ID (> 255) | Field Count | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Data Count | Common Properties ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 | Field 1 Specifier | 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 | ... | 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 | Field N Specifier | 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 | Data 1 Specifier | 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 | ... | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 | Data M Specifier | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | Data 1 Value | 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 | ... | 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 | Data M Value | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 2: Rich Template Record Format 217 The Rich Template Record field definitions are as follows: 219 Template ID 220 Template ID of this Rich Template Record. As defined in 221 [I-D.ietf-ipfix-protocol], this value MUST be greater than 255. 223 Field Count 224 Number of regular fields that will be sent in subsequent Data 225 Records using this Template, as defined in 226 [I-D.ietf-ipfix-protocol]. 228 Data Count 229 Number of fixed-value fields that will be sent in this Template. 231 Common Properties ID 232 Contains an identifier that can be referred to by 233 commonPropertiesId Information Elements, as introduced in 234 [I-D.ietf-ipfix-reducing-redundancy]. 236 Field N Specifier 237 Information Element identifier, Field length and an Enterprise 238 Number (if applicable) of field N. Refer to 239 [I-D.ietf-ipfix-protocol] for more information on Field 240 Specifiers. 242 Data M Specifier 243 Same as "Field N Specifier", but used for Common Properties of all 244 Data Records of this Template. Together with Data M Value, a 245 similar encoding like TLV (type-length-value) is achieved. 247 Data M Value 248 Bit representation of a Common Property as would be transmitted in 249 a Data Record. 251 Table 1 illustrates the relationship between field modifiers and 252 patterns on the one hand, and the resulting regular and fixed-value 253 fields in the Rich Template on the other hand. It can be seen that 254 the analyzer is able to deduce all instructions of the Aggregation 255 Rule considering the structure of the Rich Template, except the 256 combination "discard without pattern" that does not result in any 257 field. 259 +----------+---------+------------------------+---------------------+ 260 | field | pattern | field in Flow Record | fixed-value field | 261 | modifier | | | in Rich Template | 262 +----------+---------+------------------------+---------------------+ 263 | discard | no | N/A | N/A | 264 | discard | yes | N/A | yes, contains | 265 | | | | pattern | 266 | keep | no | yes | N/A | 267 | keep | yes | yes, if pattern | yes, contains | 268 | | | specifies a range of | pattern | 269 | | | values | | 270 | mask | no | yes, IP network | N/A | 271 | | | address | | 272 | mask | yes | yes, IP network | yes, contains | 273 | | | address | pattern | 274 +----------+---------+------------------------+---------------------+ 276 Table 1: Relation between field modifiers, Flow Records, and Rich 277 Templates 279 Assume, for example, the concentrator was given the Aggregation Rule 280 shown in Table 2. 282 +-------------------------+--------------+-------------+ 283 | IPFIX Field | Filtering | Aggregation | 284 +-------------------------+--------------+-------------+ 285 | sourceIPv4Address | 192.0.2.0/28 | discard | 286 | destinatonTransportPort | | keep | 287 | packetDeltaCount | | aggregate | 288 +-------------------------+--------------+-------------+ 290 Table 2: Example Rule 292 Based on the Aggregation Rule, the concentrator would now first send 293 a corresponding Rich Template Record as shown in Table 3. 295 +----------------------+------------------+ 296 | Field | Value | 297 +----------------------+------------------+ 298 | Template ID | 10001 | 299 | Field Count | 2 | 300 | Data Count | 2 | 301 | Common Properties ID | 0 | 302 | Field 1 Type | Destination Port | 303 | Field 2 Type | Packets | 304 | Data 1 Type | Source IP Prefix | 305 | Data 2 Type | Source IP Mask | 306 | Data 1 Value | 192.0.2.0 | 307 | Data 2 Value | 28 | 308 +----------------------+------------------+ 310 Table 3: Rich Template used 312 Assume further that the concentrator receives the Flow Records shown 313 in Table 4. 315 +-------------+-----------+--------------+----------------+---------+ 316 | Source IP | Source | Destination | Destination | Packets | 317 | | Port | IP | Port | | 318 +-------------+-----------+--------------+----------------+---------+ 319 | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | 320 | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | 321 | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | 322 | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | 323 | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | 324 +-------------+-----------+--------------+----------------+---------+ 326 Table 4: Incoming Flows 328 The concentrator would then export Data Records of this type, which 329 contain the Compound Flows resulting from aggregation. Note that the 330 Flows' Common Property, having a source IP address in 192.0.2.0/28, 331 was already transmitted in the Rich Template Record and is thus not 332 included in Data Records. The exported Data Records, shown in 333 Table 5, only contain the aggregated packet counts and the 334 destination port, the latter being the only discriminating Flow Key 335 property. 337 +------------------+---------+ 338 | Destination Port | Packets | 339 +------------------+---------+ 340 | 80 | 20 | 341 | 110 | 10 | 342 +------------------+---------+ 344 Table 5: Aggregated Flows 346 4. Abstract data type ipv4Network 348 Currently, the transport of IP network information as specified by 349 IPFIX is done using separate fields for the network address and the 350 corresponding mask. We propose a new abstract data type ipv4Network 351 that represents the common notation of IP networks: address/mask. 353 The ipv4Network abstract data type extends the abstract data type 354 ipv4Address to allow a concatenated unsigned8 specifying the prefix 355 length. Alternatively, Information Elements based on the ipv4Network 356 abstract data type MAY be transmitted using reduced size encoding to 357 transmit only the network part of an IPv4 address. In ABNF-style 358 notation, the syntax can be summed up as follows: 360 ipv4Network = ipv4Address unsigned8 361 ipv4Network =/ *4( unsigned8 ) 363 Although using an ipv4Network field instead of two separate fields 364 for prefix and mask will not reduce the length of resulting Flow 365 Records, it eases the work of the aggregator: With ipv4Network, the 366 comparison of subnet addresses requires only one field lookup per 367 Flow Record instead of two. Furthermore, using the abstract data 368 type ipv4Network reduces the Template size by one field equalling 369 four octets. Applications such as IPFIX Aggregation benefit from 370 ipv4Network if network addresses are frequently exported. 372 5. Abstract data type portRanges 374 For some applications it might be useful to restrict the 375 applicability of an Aggregation Rule to Flows with source or 376 destination port being of a specific set of port numbers. In an 377 Aggregation Rule, such a set of port numbers can be specified as a 378 pattern. However, the current IPFIX Information Model does not 379 define any data type that allows transmitting a set of port numbers, 380 which is necessary in order to export the pattern as a Common 381 Property of the resulting Compound Flows. Therefore, the new 382 abstract data type portRanges for a list of port ranges is defined in 383 this section. 385 The abstract data type portRanges is a finite-length concatenation of 386 unsigned16 value pairs, each consisting of the port range's first and 387 last port number. Data types basing on portRanges MAY also be cast 388 down to unsigned16 using reduced size encoding to represent a single 389 Port. Hence, the transportSourcePort and transportDestinationPort 390 data types, currently based on the unsigned16 abstract data type, can 391 also be parsed as portRanges-based data types. In ABNF-style 392 notation, the syntax can be summed up as follows: 394 portRanges = *(unsigned16 unsigned16) 395 portRanges =/ unsigned16 397 An Information Element basing on portRanges MAY also be used as a 398 variable-length Information Elements by prefixing it with a one-octet 399 or three-octet length specifier as defined in 400 [I-D.ietf-ipfix-protocol]. 402 Table 6 shows some encoding examples with portRanges. 404 +---------------+--------+-------------------------------+ 405 | Port Ranges | Octets | Hexadecimal Representation | 406 +---------------+--------+-------------------------------+ 407 | 80 | 2 | 0050 | 408 | 1:7 | 4 | 0001 0007 | 409 | 80, 443 | 8 | 0050 0050 01BB 01BB | 410 | 1:7, 256:1024 | 8 | 0001 0007 0100 0400 | 411 | 20, 80, 443 | 12 | 0014 0014 0050 0050 01BB 01BB | 412 | 1:7, 80, 443 | 12 | 0001 0007 0050 0050 01BB 01BB | 413 +---------------+--------+-------------------------------+ 415 Table 6: PortRanges Examples 417 6. excludedPropertiesId Information Element 419 The IPFIX Information Model [I-D.ietf-ipfix-info] defines the 420 commonPropertiesId Information Element, which can be used to link to 421 information which several Flows have in common. 423 Similarly, the excludedPropertiesId shall be defined to link to a set 424 of Common Properties which a Flow does explicitly not exhibit. An 425 ElementId of 239 is proposed for this Information Element. 427 The excludedPropertiesId works like a boolean "and not" operation on 428 the linked properties. This means that, if an excludedPropertiesId 429 refers to a set of Common Properties which in turn specifies excluded 430 properties, these transitively referenced properties are to be 431 treated as if directly referenced via a commonPropertiesId element 432 and, hence, as being present in the Flow in question. 434 The excludedPropertiesId can, for example, be used when a hierarchy 435 of Aggregation Rules with a "preceding rule" semantic, as introduced 436 in [I-D.dressler-ipfix-aggregation], is configured in an IPFIX 437 Aggregator. 439 Figure 5 illustrates the use of Common Property definitions and the 440 linking to these definitions with Information Elements of types 441 commonPropertiesId (CP) and excludedPropertiesId (EP). In this 442 example, two rules are defined in the aggregator: Rule 1 matches 443 Flows with a sourceIPv4Address of 192.0.2.1, Rule 2 matches Flows 444 with a destinationIPv4Address of 192.0.2.2. Furthermore, Rule 1 is 445 configured to precede Rule 2 in a hierarchy of rules, i.e. Flows 446 that matched Rule 1 will never match Rule 2. 448 In order to communicate this fact to a receiver, each Aggregation 449 Rule is transmitted as two sets of Common Properties. One set of 450 properties (shown on the right hand side of Figure 5) directly 451 transmits a rule's filtering criteria. The other set of properties 452 (shown on the left hand side) refers via a commonPropertiesId to all 453 properties that a Compound Flow exhibits, as well as via an 454 excludedPropertiesId to all that the Compound Flow does not exhibit. 456 The Flow depicted at the bottom of Figure 5 thus communicates a 457 source port of 80, a destination port of 65432, a destination IP of 458 192.0.2.2 and a source IP of "not 192.0.2.1". However, besides the 459 transmission of this Flow in one Data Record, previous transmissions 460 (and the successful reception) of four Option Templates, four Option 461 Data Records and one Template are required to communicate this 462 information. 464 Rule 1: 465 +########+------+ +######+---------------+ 466 # CP=101 # CP=1 |<-----------># CP=1 # SRC=192.0.2.1 | 467 +########+------+ +######+---------------+ 468 ^ 469 .--------------------' 470 Rule 2: v 471 +########+------+------+ +######+---------------+ 472 # CP=102 # EP=1 | CP=2 |<----># CP=2 # DST=192.0.2.2 | 473 +########+------+------+ +######+---------------+ 474 ^ 475 '-------------------. 476 Flow: v 477 +--------+-----------+--------+ 478 | SPT=80 | DPT=65432 | CP=102 | 479 +--------+-----------+--------+ 481 Figure 5: Using excludedPropertiesId to communicate a rule hierarchy 483 7. precedingRulePropertiesId Information Element 485 The only aspect in which the precedingRulePropertiesId Information 486 Element differs from the excludedPropertiesId Information Element 487 introduced in Section 6 is that transitive references are handled 488 differently. 490 Unlike the excludedPropertiesId, the precedingRulePropertiesId does 491 not work like a boolean "and not" operation on the linked properties. 492 This means that, if a precedingRulePropertiesId refers to a set of 493 Common Properties which in turn specifies excluded properties, these 494 transitively referenced properties are to be treated as being 495 excluded from the Flow in question, too. 497 Analogous to excludedPropertiesId, the precedingRulePropertiesId (PP) 498 Information Element can be used to communicate the hierarchy of rules 499 introduced in the example of Section 6. As illustrated in Figure 6, 500 the amount of data transmitted is now significantly smaller, while 501 communicating the exact same information: A source port of 80, a 502 destination port of 65432, a destination IP of 192.0.2.2 and a source 503 IP of "not 192.0.2.1". Besides the transmission of the Flow in one 504 Data Record it only requires the previous transmissions (and the 505 successful reception) of two Rich Templates. 507 Rule 1: 508 +---------------+ 509 | SRC=192.0.2.1 |<---. (Rich Template 1234, CP=101) 510 +---------------+ | 511 | 512 | 513 Rule 2: | 514 +---------------+--------+ 515 | DST=192.0.2.2 | PP=101 | (Rich Template 1235) 516 +---------------+--------+ 518 Flow: 519 +--------+-----------+ 520 | SPT=80 | DPT=65432 | (Based on Rich Template 1235) 521 +--------+-----------+ 523 Figure 6: Using precedingRulePropertiesId to communicate a rule 524 hierarchy 526 8. Security considerations 528 As all methods described in this document are merely variations on 529 methods already introduced in [I-D.ietf-ipfix-protocol], the same 530 rules regarding exchange of Flow information apply. 532 9. IANA Considerations 534 Use of the Rich Template Set requires one new IPFIX Set ID to be 535 assigned. Use of excludedPropertiesId, precedingRulePropertiesId, as 536 well as use of a data type basing on ipv4Network or on portRanges 537 requires one new IPFIX Information Element identifier each to be 538 assigned. 540 10. References 542 10.1. Normative References 544 [I-D.ietf-ipfix-protocol] 545 Claise, B., "Specification of the IPFIX Protocol for the 546 Exchange of IP Traffic Flow Information", 547 draft-ietf-ipfix-protocol-26 (work in progress), 548 September 2007. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 554 Specifications: ABNF", RFC 4234, October 2005. 556 10.2. Informative References 558 [I-D.dressler-ipfix-aggregation] 559 Dressler, F., "IPFIX Aggregation", 560 draft-dressler-ipfix-aggregation-03 (work in progress), 561 June 2006. 563 [I-D.ietf-ipfix-info] 564 Quittek, J., "Information Model for IP Flow Information 565 Export", draft-ietf-ipfix-info-15 (work in progress), 566 February 2007. 568 [I-D.ietf-ipfix-reducing-redundancy] 569 Boschi, E., "Reducing Redundancy in IP Flow Information 570 Export (IPFIX) and Packet Sampling (PSAMP) Reports", 571 draft-ietf-ipfix-reducing-redundancy-04 (work in 572 progress), May 2007. 574 Authors' Addresses 576 Christoph Sommer 577 University of Erlangen-Nuremberg 578 Department of Computer Science 7 579 Martensstr. 3 580 Erlangen 91058 581 Germany 583 Phone: +49 9131 85-27993 584 Email: christoph.sommer@informatik.uni-erlangen.de 585 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 586 Falko Dressler 587 University of Erlangen-Nuremberg 588 Department of Computer Science 7 589 Martensstr. 3 590 Erlangen 91058 591 Germany 593 Phone: +49 9131 85-27914 594 Email: dressler@informatik.uni-erlangen.de 595 URI: http://www7.informatik.uni-erlangen.de/ 597 Gerhard Muenz 598 University of Tuebingen 599 Computer Networks and Internet 600 Sand 13 601 Tuebingen 72076 602 Germany 604 Phone: +49 7071 29-70534 605 Email: muenz@informatik.uni-tuebingen.de 606 URI: http://net.informatik.uni-tuebingen.de/ 608 Full Copyright Statement 610 Copyright (C) The IETF Trust (2007). 612 This document is subject to the rights, licenses and restrictions 613 contained in BCP 78, and except as set forth therein, the authors 614 retain all their rights. 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 619 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 620 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 621 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any 636 assurances of licenses to be made available, or the result of an 637 attempt made to obtain a general license or permission for the use of 638 such proprietary rights by implementers or users of this 639 specification can be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at 646 ietf-ipr@ietf.org. 648 Acknowledgment 650 Funding for the RFC Editor function is provided by the IETF 651 Administrative Support Activity (IASA).