idnits 2.17.1 draft-sommer-ipfix-richtemplate-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 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 (July 7, 2008) is 5743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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 Intended status: Informational Univ. Erlangen 5 Expires: January 8, 2009 G. Muenz 6 Univ. Tuebingen 7 July 7, 2008 9 Rich Template Set Extension to the IPFIX Protocol 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 January 8, 2009. 37 Abstract 39 This draft describes the Rich Template Set, a Template Set for the 40 IPFIX Protocol, as well as its respective Template Records. One 41 possible application domain for this new Set is the transport of 42 IPFIX Flow Mediation selection criteria. In comparison to the use of 43 Common Properties, the use of Rich Template Sets reduces the overhead 44 of repeated transmissions and makes data transmissions more robust 45 against failures. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Rich Template . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Use of the Rich Template in Flow Aggregation . . . . . . . . . 7 52 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 54 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 56 Intellectual Property and Copyright Statements . . . . . . . . . . 11 58 1. Introduction 60 IPFIX supports the concept of a Mediator, a device that receives, 61 transforms, and exports data streams using IPFIX. A major 62 requirement of flow mediation is the reduction of the volume of IPFIX 63 traffic by discarding and aggregating received information. 64 [I-D.dressler-ipfix-aggregation] describes how pattern matching is 65 used for flow aggregation. The draft also outlines how to select 66 flows and subsequently communicate the selection criteria to an IPFIX 67 Collector, using Common Properties of the resulting Compound Flows to 68 describe these attributes. In order to avoid the overhead of the 69 repeated transmissions of all Common Properties (or their 70 identifiers) in all Flow Records, a new Template Set, the Rich 71 Template Set, is introduced. This Template Set allows an Exporting 72 Process to simultaneously declare and transmit Common Properties to a 73 receiver. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Rich Template 81 0 1 2 3 82 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 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Set ID = 4 | Length | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | | 87 | Rich Template Record 1 | 88 | | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | | 91 | ... | 92 | | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | 95 | Rich Template Record N | 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Padding (opt) | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 Figure 1: Rich Template Set Format 103 The basic format of a Rich Template Set is shown in Figure 1. It is 104 the same as that of a Template Set defined in [RFC5101], except for a 105 different Set ID. 107 The format of individual Rich Template Records, however, differs from 108 that of Template Records and is shown in Figure 2. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Template ID (> 255) | Field Count | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Data Count | Common Properties ID | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 | Field 1 Specifier | 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 | ... | 123 | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | | 126 | Field N Specifier | 127 | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 | Data 1 Specifier | 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 | ... | 135 | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 | Data M Specifier | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | Data 1 Value | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 | ... | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | | 150 | Data M Value | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 2: Rich Template Record Format 156 The Rich Template Set field definitions are as follows: 158 Set ID 159 Type of this Template Set. A Set ID value of 4 is proposed for the 160 Rich Template Set. 162 Length 163 Total length of this set in bytes, as defined in [RFC5101]. 165 Padding 166 OPTIONAL padding, as defined in [RFC5101]. 168 The Rich Template Record field definitions are as follows: 170 Template ID 171 Template ID of this Rich Template Record. As defined in 172 [RFC5101], this value MUST be greater than 255. 174 Field Count 175 Number of regular fields that will be sent in subsequent Data 176 Records using this Template, as defined in [RFC5101]. 178 Data Count 179 Number of fixed-value fields that will be sent in this Template. 181 Common Properties ID 182 Contains an identifier that can be referred to by 183 commonPropertiesId Information Elements, as introduced in 184 [I-D.ietf-ipfix-reducing-redundancy]. 186 Field N Specifier 187 Information Element identifier, Field length and an Enterprise 188 Number (if applicable) of field N. Refer to [RFC5101] for more 189 information on Field Specifiers. 191 Data M Specifier 192 Same as "Field N Specifier", but used for Common Properties of all 193 Data Records of this Template. Together with Data M Value, a 194 similar encoding like TLV (type-length-value) is achieved. 196 Data M Value 197 Bit representation of a Common Property as would be transmitted in 198 a Data Record. 200 3. Use of the Rich Template in Flow Aggregation 202 The Rich Template is well-suited for use in flow aggregation, as 203 introduced in [I-D.dressler-ipfix-aggregation]. Table 1 illustrates 204 the relationship between a flow aggregator's field modifiers and 205 patterns on the one hand, and the resulting regular and fixed-value 206 fields in the Rich Template on the other hand. It can be seen that 207 the analyzer is able to deduce all instructions of the Aggregation 208 Rule considering the structure of the Rich Template, except the 209 combination "discard without pattern" that does not result in any 210 field. 212 +----------+---------+------------------------+---------------------+ 213 | field | pattern | field in Flow Record | fixed-value field | 214 | modifier | | | in Rich Template | 215 +----------+---------+------------------------+---------------------+ 216 | discard | no | N/A | N/A | 217 | discard | yes | N/A | yes, contains | 218 | | | | pattern | 219 | keep | no | yes | N/A | 220 | keep | yes | yes, if pattern | yes, contains | 221 | | | specifies a range of | pattern | 222 | | | values | | 223 | mask | no | yes, IP network | N/A | 224 | | | address | | 225 | mask | yes | yes, IP network | yes, contains | 226 | | | address | pattern | 227 +----------+---------+------------------------+---------------------+ 229 Table 1: Relation between field modifiers, Flow Records, and Rich 230 Templates 232 Assume, for example, the concentrator was given the Aggregation Rule 233 shown in Table 2. 235 +-------------------------+--------------+-------------+ 236 | IPFIX Field | Filtering | Aggregation | 237 +-------------------------+--------------+-------------+ 238 | sourceIPv4Address | 192.0.2.0/28 | discard | 239 | destinatonTransportPort | | keep | 240 | packetDeltaCount | | aggregate | 241 +-------------------------+--------------+-------------+ 243 Table 2: Example Rule 245 Based on the Aggregation Rule, the concentrator would now first send 246 a corresponding Rich Template Record as shown in Table 3. 248 +----------------------+------------------+ 249 | Field | Value | 250 +----------------------+------------------+ 251 | Template ID | 10001 | 252 | Field Count | 2 | 253 | Data Count | 2 | 254 | Common Properties ID | 0 | 255 | Field 1 Type | Destination Port | 256 | Field 2 Type | Packets | 257 | Data 1 Type | Source IP Prefix | 258 | Data 2 Type | Source IP Mask | 259 | Data 1 Value | 192.0.2.0 | 260 | Data 2 Value | 28 | 261 +----------------------+------------------+ 263 Table 3: Rich Template used 265 Assume further that the concentrator receives the Flow Records shown 266 in Table 4. 268 +-------------+-----------+--------------+----------------+---------+ 269 | Source IP | Source | Destination | Destination | Packets | 270 | | Port | IP | Port | | 271 +-------------+-----------+--------------+----------------+---------+ 272 | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | 273 | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | 274 | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | 275 | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | 276 | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | 277 +-------------+-----------+--------------+----------------+---------+ 279 Table 4: Incoming Flows 281 The concentrator would then export Data Records of this type, which 282 contain the Compound Flows resulting from aggregation. Note that the 283 Flows' Common Property, having a source IP address in 192.0.2.0/28, 284 was already transmitted in the Rich Template Record and is thus not 285 included in Data Records. 287 The exported Data Records, shown in Table 5, only contain the 288 aggregated packet counts and the destination port, the latter being 289 the only discriminating Flow Key property. 291 +------------------+---------+ 292 | Destination Port | Packets | 293 +------------------+---------+ 294 | 80 | 20 | 295 | 110 | 10 | 296 +------------------+---------+ 298 Table 5: Aggregated Flows 300 4. Security considerations 302 This document introduces a new IPFIX Template Set, a variation on the 303 Template Set and data types introduced in [RFC5101] and 304 [I-D.ietf-ipfix-reducing-redundancy]. No additional security 305 considerations apply. 307 5. IANA Considerations 309 Use of the Rich Template Set requires one new IPFIX Set ID to be 310 assigned. 312 6. Normative References 314 [I-D.dressler-ipfix-aggregation] 315 Dressler, F., "IPFIX Aggregation", 316 draft-dressler-ipfix-aggregation-05 (work in progress), 317 July 2008. 319 [I-D.ietf-ipfix-reducing-redundancy] 320 Boschi, E., "Reducing Redundancy in IP Flow Information 321 Export (IPFIX) and Packet Sampling (PSAMP) Reports", 322 draft-ietf-ipfix-reducing-redundancy-04 (work in 323 progress), May 2007. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC5101] Claise, B., "Specification of the IP Flow Information 329 Export (IPFIX) Protocol for the Exchange of IP Traffic 330 Flow Information", RFC 5101, January 2008. 332 Authors' Addresses 334 Christoph Sommer 335 University of Erlangen-Nuremberg 336 Department of Computer Science 7 337 Martensstr. 3 338 Erlangen 91058 339 Germany 341 Phone: +49 9131 85-27993 342 Email: christoph.sommer@informatik.uni-erlangen.de 343 URI: http://www7.informatik.uni-erlangen.de/~sommer/ 345 Falko Dressler 346 University of Erlangen-Nuremberg 347 Department of Computer Science 7 348 Martensstr. 3 349 Erlangen 91058 350 Germany 352 Phone: +49 9131 85-27914 353 Email: dressler@informatik.uni-erlangen.de 354 URI: http://www7.informatik.uni-erlangen.de/ 356 Gerhard Muenz 357 University of Tuebingen 358 Computer Networks and Internet 359 Sand 13 360 Tuebingen 72076 361 Germany 363 Phone: +49 7071 29-70534 364 Email: muenz@informatik.uni-tuebingen.de 365 URI: http://net.informatik.uni-tuebingen.de/ 367 Full Copyright Statement 369 Copyright (C) The IETF Trust (2008). 371 This document is subject to the rights, licenses and restrictions 372 contained in BCP 78, and except as set forth therein, the authors 373 retain all their rights. 375 This document and the information contained herein are provided on an 376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 378 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 379 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Intellectual Property 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org.