idnits 2.17.1 draft-ietf-ipfix-protocol-rfc5101bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 and authors Copyright Line does not match the current year -- The document date (December 19, 2012) is 4145 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Possible downref: Normative reference to a draft: ref. 'RFC5102bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-IANA' -- Obsolete informational reference (is this intentional?): RFC 5101 (ref. 'RFC5103') (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-mediation-protocol-02 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Obsoletes: 5101 B. Trammell, Ed. 5 Category: Standards Track ETH Zurich 6 Expires: June 22, 2013 December 19, 2012 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of Flow Information 10 draft-ietf-ipfix-protocol-rfc5101bis-04 12 Abstract 14 This document specifies the IP Flow Information Export (IPFIX) 15 protocol that serves for transmitting Traffic Flow information over 16 the network. In order to transmit Traffic Flow information from an 17 Exporting Process to an information Collecting Process, a common 18 representation of flow data and a standard means of communicating 19 them is required. This document describes how the IPFIX Data and 20 Template Records are carried over a number of transport protocols 21 from an IPFIX Exporting Process to an IPFIX Collecting Process. This 22 document obsoletes RFC 5101. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 22, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Changes since RFC 5101 . . . . . . . . . . . . . . . . . . 4 60 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1. Terminology Summary Table . . . . . . . . . . . . . . . . 11 63 3. IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 11 64 3.1. Message Header Format . . . . . . . . . . . . . . . . . . 13 65 3.2. Field Specifier Format . . . . . . . . . . . . . . . . . . 14 66 3.3. Set and Set Header Format . . . . . . . . . . . . . . . . 15 67 3.3.1. Set Format . . . . . . . . . . . . . . . . . . . . . . 16 68 3.3.2. Set Header Format . . . . . . . . . . . . . . . . . . 17 69 3.4. Record Format . . . . . . . . . . . . . . . . . . . . . . 17 70 3.4.1. Template Record Format . . . . . . . . . . . . . . . . 17 71 3.4.2. Options Template Record Format . . . . . . . . . . . . 20 72 3.4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . 20 73 3.4.2.2. Options Template Record Format . . . . . . . . . . 20 74 3.4.3. Data Record Format . . . . . . . . . . . . . . . . . . 23 75 4. Specific Reporting Requirements . . . . . . . . . . . . . . . 24 76 4.1. The Metering Process Statistics Options Template . . . . . 24 77 4.2. The Metering Process Reliability Statistics Options 78 Template . . . . . . . . . . . . . . . . . . . . . . . . . 25 79 4.3. The Exporting Process Reliability Statistics Options 80 Template . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 4.4. The Flow Keys Options Template . . . . . . . . . . . . . . 28 82 5. Timing Considerations . . . . . . . . . . . . . . . . . . . . 28 83 5.1 IPFIX Message Header Export Time and Flow Record Time . . . 28 84 5.2 Supporting Timestamp Wraparound . . . . . . . . . . . . . . 29 85 6. Linkage with the Information Model . . . . . . . . . . . . . . 29 86 6.1. Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 30 87 6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 30 88 6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 30 89 6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 30 90 6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 30 91 6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 30 92 6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 30 93 6.1.8. dateTimeMilliseconds . . . . . . . . . . . . . . . . . 31 94 6.1.9 dateTimeMicroseconds . . . . . . . . . . . . . . . . . 31 95 6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 31 96 6.2. Reduced Size Encoding . . . . . . . . . . . . . . . . . . 32 97 7. Variable-Length Information Element . . . . . . . . . . . . . 33 98 8. Template Management . . . . . . . . . . . . . . . . . . . . . 34 99 8.1. Template Withdrawal and Redefinition . . . . . . . . . . . 35 100 8.2 Sequencing Template Management Actions . . . . . . . . . . 37 101 8.3. Additional considerations for Template Management over 102 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 8.4. Additional considerations for Template Management over 104 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 105 9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 40 106 9.1. Additional considerations for SCTP Collecting Processes . 41 107 9.2. Additional considerations for UDP Collecting Processes . . 41 108 10. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 41 109 10.1. Transport Compliance and Transport Usage . . . . . . . . 42 110 10.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 42 111 10.2.1. Congestion Avoidance . . . . . . . . . . . . . . . . 42 112 10.2.2. Reliability . . . . . . . . . . . . . . . . . . . . . 43 113 10.2.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 10.2.4. Association Establishment and Shutdown . . . . . . . 43 115 10.2.5. Failover . . . . . . . . . . . . . . . . . . . . . . 44 116 10.2.6. Streams . . . . . . . . . . . . . . . . . . . . . . . 44 117 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 118 10.3.1. Congestion Avoidance . . . . . . . . . . . . . . . . 44 119 10.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 45 120 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45 121 10.3.4. Session Establishment and Shutdown . . . . . . . . . 45 122 10.3.5. Failover and Session Duplication . . . . . . . . . . 45 123 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 124 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 46 125 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 46 126 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 46 127 10.4.4. Connection Establishment, Shutdown, and Restart . . . 47 128 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 47 129 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 130 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 49 131 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 49 132 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 50 133 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 50 134 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 52 135 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 52 136 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 53 137 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 138 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 54 139 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 54 140 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 55 141 A.2.1. Template Set Using IETF-Specified Information 142 Elements . . . . . . . . . . . . . . . . . . . . . . . 55 143 A.2.2. Template Set Using Enterprise-Specific Information 144 Elements . . . . . . . . . . . . . . . . . . . . . . . 55 145 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 57 146 A.4. Options Template Set Examples . . . . . . . . . . . . . . 58 147 A.4.1. Options Template Set Using IETF-Specified 148 Information Elements . . . . . . . . . . . . . . . . . 58 149 A.4.2. Options Template Set Using Enterprise-Specific 150 Information . . . . . . . . . . . . . . . . . . . . . 58 151 A.4.3. Options Template Set Using an Enterprise-Specific 152 Scope . . . . . . . . . . . . . . . . . . . . . . . . 59 153 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 60 154 A.5. Variable-Length Information Element Examples . . . . . . . 61 155 A.5.1. Example of Variable-Length Information Element with 156 Length . . . . . . . . . . . . . . . . . . . . . . . . 61 157 A.5.2. Example of Variable-Length Information Element with 158 3 Octet Length Encoding . . . . . . . . . . . . . . . 61 159 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 160 Normative References . . . . . . . . . . . . . . . . . . . . . . . 61 161 Informative References . . . . . . . . . . . . . . . . . . . . . . 63 162 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 65 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 165 1. Introduction 167 Traffic on a data network can be seen as consisting of flows passing 168 through network elements. It is often interesting, useful, or even 169 necessary to have access to information about these flows that pass 170 through the network elements for administrative or other purposes. A 171 Collecting Process should be able to receive the flow information 172 passing through multiple network elements within the data network. 173 This requires uniformity in the method of representing the flow 174 information and the means of communicating the flows from the network 175 elements to the collection point. This document specifies a protocol 176 to achieve these requirements. This document specifies in detail the 177 representation of different flows, the additional data required for 178 flow interpretation, packet format, transport mechanisms used, 179 security concerns, etc. 181 1.1. Changes since RFC 5101 183 This document obsoletes the Proposed Standard revision of the IPFIX 184 Protocol Specification [RFC5101]. The protocol specified by this 185 document is interoperable with the protocol as specified in 187 [RFC5101]. The following changes have been made to this document with 188 respect to the previous document: 190 - All outstanding technical and editorial errata on RFC5101 have been 191 addressed. 193 - The encoding of the dateTimeSeconds, dateTimeMilliseconds, 194 dateTimeMicroseconds, and dateTimeNanoseconds data types, and the 195 related encoding of the IPFIX Message Header Export Time field, have 196 been clarified, especially with respect to the epoch upon which the 197 timestamp data types are based. 199 - A new Section 5.2 has been added to address wraparound of these 200 timestamp data types. 202 - Clarifications on encoding, especially in Section 6: all IPFIX 203 values are encoded big-endian. 205 - Template management in section 8 has been simplified and clarified. 207 - Editorial changes, including structural changes to sections 8, 9, 208 and 10 to improve readability. 210 1.2. IPFIX Documents Overview 212 The IPFIX protocol provides network administrators with access to IP 213 flow information. The architecture for the export of measured IP 214 flow information out of an IPFIX Exporting Process to a Collecting 215 Process is defined in [RFC5470], per the requirements defined in 216 [RFC3917]. This document specifies how IPFIX data records and 217 templates are carried via a number of transport protocols from IPFIX 218 Exporting Processes to IPFIX Collecting Processes. 220 Four IPFIX optimizations/extensions are currently specified: a 221 bandwidth saving method for the IPFIX protocol in [RFC5473], an 222 efficient method for exporting bidirectional flows in [RFC5103], a 223 method for the definition and export of complex data structures in 224 [RFC6313], and the specification of the Protocol for IPFIX Mediations 225 [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183]. 227 A "file-based transport" for IPFIX, which defines how IPFIX Messages 228 can be stored in files for document-based workflows and for archival 229 purposes, is given in [RFC5655]. 231 IPFIX has a formal description of IPFIX Information Elements, their 232 name, type and additional semantic information, as specified in 233 [RFC5102bis]. The registry is maintained by IANA [IPFIX-IANA]. The 234 inline export of the Information Element type informationis 235 specified in [RFC5610]. 237 [RFC6728] specifies a data model for configuring and monitoring IPFIX 238 and PSAMP compliant devices using the NETCONF protocol, while 239 [RFC6615] specifies a MIB module for monitoring. 241 In terms of development, [RFC5153] provides guidelines for the 242 implementation and use of the IPFIX protocol, while [RFC5471] 243 provides guidelines for testing. Finally, [RFC5472] describes what 244 type of applications can use the IPFIX protocol and how they can use 245 the information provided. It furthermore shows how the IPFIX 246 framework relates to other architectures and frameworks. 248 2. Terminology 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in RFC 2119 [RFC2119]. 254 The definitions of the basic terms like Traffic Flow, Exporting 255 Process, Collecting Process, Observation Points, etc. are 256 semantically identical to those found in the IPFIX requirements 257 document [RFC3917]. Some of the terms have been expanded for more 258 clarity when defining the protocol. Additional terms required for 259 the protocol have also been defined. Definitions in this document 260 and in [RFC5470] are equivalent; definitions that are only relevant 261 to the IPFIX protocol only appear here. 263 The terminology summary table in Section 2.1 gives a quick overview 264 of the relationships between some of the different terms defined. 266 Observation Point 268 An Observation Point is a location in the network where packets 269 can be observed. Examples include: a line to which a probe is 270 attached, a shared medium, such as an Ethernet-based LAN, a single 271 port of a router, or a set of interfaces (physical or logical) of 272 a router. 274 Note that every Observation Point is associated with an 275 Observation Domain (defined below), and that one Observation Point 276 may be a superset of several other Observation Points. For 277 example, one Observation Point can be an entire line card. That 278 would be the superset of the individual Observation Points at the 279 line card's interfaces. 281 Observation Domain 283 An Observation Domain is the largest set of Observation Points for 284 which Flow information can be aggregated by a Metering Process. 285 For example, a router line card may be an Observation Domain if it 286 is composed of several interfaces, each of which is an Observation 287 Point. In the IPFIX Message it generates, the Observation Domain 288 includes its Observation Domain ID, which is unique per Exporting 289 Process. That way, the Collecting Process can identify the 290 specific Observation Domain from the Exporter that sends the IPFIX 291 Messages. Every Observation Point is associated with an 292 Observation Domain. It is RECOMMENDED that Observation Domain IDs 293 also be unique per IPFIX Device. 295 Traffic Flow or Flow 297 There are several definitions of the term 'flow' being used by the 298 Internet community. Within the context of IPFIX we use the 299 following definition: 301 A Flow is defined as a set of packets or frames passing an 302 Observation Point in the network during a certain time interval. 303 All packets belonging to a particular Flow have a set of common 304 properties. Each property is defined as the result of applying a 305 function to the values of: 307 1. one or more packet header fields (e.g., destination IP 308 address), transport header fields (e.g., destination port 309 number), or application header fields (e.g., RTP header 310 fields [RFC3550]). 312 2. one or more characteristics of the packet itself (e.g., 313 number of MPLS labels, etc...). 315 3. one or more of fields derived from packet treatment (e.g., 316 next hop IP address, the output interface, etc...). 318 A packet is defined as belonging to a Flow if it completely 319 satisfies all the defined properties of the Flow. 321 Note that the set of packets represented by a Flow may be empty; 322 that is, a Flow may represent zero or more packets. As sampling is 323 a packet treatment, this definition includes packets selected by a 324 sampling mechanism. 326 Flow Key 328 Each of the fields that: 330 1. belong to the packet header (e.g., destination IP address), or 332 2. are a property of the packet itself (e.g., packet length), or 334 3. are derived from packet treatment (e.g., Autonomous System 335 (AS) number), 337 and that are used to define a Flow are termed Flow Keys. 339 Flow Record 341 A Flow Record contains information about a specific Flow that was 342 observed at an Observation Point. A Flow Record contains measured 343 properties of the Flow (e.g., the total number of bytes for all 344 the Flow's packets) and usually contains characteristic properties 345 of the Flow (e.g., source IP address). 347 Metering Process 349 The Metering Process generates Flow Records. Inputs to the 350 process are packet headers, characteristics, and packet treatment 351 observed at one or more Observation Points. 353 The Metering Process consists of a set of functions that includes 354 packet header capturing, timestamping, sampling, classifying, and 355 maintaining Flow Records. 357 The maintenance of Flow Records may include creating new records, 358 updating existing ones, computing Flow statistics, deriving 359 further Flow properties, detecting Flow expiration, passing Flow 360 Records to the Exporting Process, and deleting Flow Records. 362 Exporting Process 364 The Exporting Process sends IPFIX Messages to one or more 365 Collecting Processes. The Flow Records in the Messages are 366 generated by one or more Metering Processes. 368 Exporter 370 A device that hosts one or more Exporting Processes is termed an 371 Exporter. 373 IPFIX Device 375 An IPFIX Device hosts at least one Exporting Process. It may host 376 further Exporting Processes and arbitrary numbers of Observation 377 Points and Metering Processes. 379 Collecting Process 381 A Collecting Process receives IPFIX Messages from one or more 382 Exporting Processes. The Collecting Process might process or 383 store Flow Records received within these Messages, but such 384 actions are out of scope for this document. 386 Collector 388 A device that hosts one or more Collecting Processes is termed a 389 Collector. 391 Template 393 A Template is an ordered sequence of pairs used to 394 completely specify the structure and semantics of a particular set 395 of information that needs to be communicated from an IPFIX Device 396 to a Collector. Each Template is uniquely identifiable by means 397 of a Template ID. 399 IPFIX Message 401 An IPFIX Message is a message originating at the Exporting Process 402 that carries the IPFIX records of this Exporting Process and whose 403 destination is a Collecting Process. An IPFIX Message is 404 encapsulated at the transport layer. 406 Message Header 408 The Message Header is the first part of an IPFIX Message, which 409 provides basic information about the message, such as the IPFIX 410 version, length of the message, message sequence number, etc. 412 Template Record 414 A Template Record defines the structure and interpretation of 415 fields in a Data Record. 417 Data Record 419 A Data Record is a record that contains values of the parameters 420 corresponding to a Template Record. 422 Options Template Record 424 An Options Template Record is a Template Record that defines the 425 structure and interpretation of fields in a Data Record, including 426 defining how to scope the applicability of the Data Record. 428 Set 430 A Set is a collection of records that have a similar structure, 431 prefixed by a header. In an IPFIX Message, zero or more Sets 432 follow the Message Header. There are three different types of 433 Sets: Template Set, Options Template Set, and Data Set. 435 Template Set 437 A Template Set is a collection of one or more Template Records 438 that have been grouped together in an IPFIX Message. 440 Options Template Set 442 An Options Template Set is a collection of one or more Options 443 Template Records that have been grouped together in an IPFIX 444 Message. 446 Data Set 448 A Data Set is one or more Data Records, of the same type, that are 449 grouped together in an IPFIX Message. Each Data Record is 450 previously defined by a Template Record or an Options Template 451 Record. 453 Information Element 455 An Information Element is a protocol and encoding-independent 456 description of an attribute that may appear in an IPFIX Record. 457 The base set of Information Elements making up the IPFIX 458 information model [RFC5102bis] are described in the IANA IPFIX 459 Information Element Registry [IPFIX-IANA]. The type associated 460 with an Information Element indicates constraints on what it may 461 contain and also determines the valid encoding mechanisms for use 462 in IPFIX. 464 Transport Session 466 In Stream Control Transmission Protocol (SCTP), the transport 467 session is known as the SCTP association, which is uniquely 468 identified by the SCTP endpoints [RFC4960]; in TCP, the transport 469 session is known as the TCP connection, which is uniquely 470 identified by the combination of IP addresses and TCP ports used. 471 In UDP, the transport session is known as the UDP session, which 472 is uniquely identified by the combination of IP addresses and UDP 473 ports used. 475 2.1. Terminology Summary Table 477 +------------------+---------------------------------------------+ 478 | | contents | 479 | +--------------------+------------------------+ 480 | Set | Template | Record | 481 +------------------+--------------------+------------------------+ 482 | Data Set | / | Data Record(s) | 483 +------------------+--------------------+------------------------+ 484 | Template Set | Template Record(s) | / | 485 +------------------+--------------------+------------------------+ 486 | Options Template | Options Template | / | 487 | Set | Record(s) | | 488 +------------------+--------------------+------------------------+ 490 Figure A: Terminology Summary Table 492 A Data Set is composed of Data Record(s). No Template Record is 493 included. A Template Record or an Options Template Record defines 494 the Data Record. 496 A Template Set contains only Template Record(s). 498 An Options Template Set contains only Options Template Record(s). 500 3. IPFIX Message Format 502 An IPFIX Message consists of a Message Header, followed by one or 503 more Sets. The Sets can be any of the possible three types: Data 504 Set, Template Set, or Options Template Set. 506 The format of the IPFIX Message is shown in Figure B. 508 +----------------------------------------------------+ 509 | Message Header | 510 +----------------------------------------------------+ 511 | Set | 512 +----------------------------------------------------+ 513 | Set | 514 +----------------------------------------------------+ 515 ... 516 +----------------------------------------------------+ 517 | Set | 518 +----------------------------------------------------+ 520 Figure B: IPFIX Message Format 521 Following are some examples of IPFIX Messages: 523 1. An IPFIX Message consisting of interleaved Template, Data, and 524 Options Template Sets, shown in Figure C. Here, Template and 525 Options Template Sets are transmitted "on demand", before the 526 first Data Set they define the structure of. 528 +--------+--------------------------------------------------------+ 529 | | +----------+ +---------+ +-----------+ +---------+ | 530 |Message | | Template | | Data | | Options | | Data | | 531 | Header | | Set | | Set | ... | Template | | Set | | 532 | | | | | | | Set | | | | 533 | | +----------+ +---------+ +-----------+ +---------+ | 534 +--------+--------------------------------------------------------+ 536 Figure C: IPFIX Message, Example 1 538 2. An IPFIX Message consisting entirely of Data Sets, sent after the 539 appropriate Template Records have been defined and transmitted to 540 the Collecting Process, shown in Figure D. 542 +--------+----------------------------------------------+ 543 | | +---------+ +---------+ +---------+ | 544 |Message | | Data | | Data | | Data | | 545 | Header | | Set | ... | Set | ... | Set | | 546 | | +---------+ +---------+ +---------+ | 547 +--------+----------------------------------------------+ 549 Figure D: IPFIX Message, Example 2 551 3. An IPFIX Message consisting entirely of Template and Options 552 Template Sets, shown in Figure E. Such a message can be used to 553 define or redefine Templates and Options Templates in bulk. 555 +--------+-------------------------------------------------+ 556 | | +----------+ +----------+ +----------+ | 557 |Message | | Template | | Template | | Options | | 558 | Header | | Set | ... | Set | ... | Template | | 559 | | | | | | | Set | | 560 | | +----------+ +----------+ +----------+ | 561 +--------+-------------------------------------------------+ 563 Figure E: IPFIX Message, Example 3 565 3.1. Message Header Format 567 The format of the IPFIX Message Header is shown in Figure F. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Version Number | Length | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Export Time | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Sequence Number | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Observation Domain ID | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure F: IPFIX Message Header Format 583 Each Message Header field is exported in big-endian byte order. The 584 fields are defined as follows: 586 Version 588 Version of IPFIX to which this Message conforms. The value of this 589 field is 0x000a for the current version, incrementing by one the 590 version used in the NetFlow services export version 9 [RFC3954]. 592 Length 594 Total length of the IPFIX Message, measured in octets, including 595 Message Header and Set(s). 597 Export Time 599 Time at which the IPFIX Message Header leaves the Exporter, 600 expressed in seconds since the UNIX epoch of 1 January 1970 at 601 00:00 UTC, encoded as an unsigned 32-bit integer. 603 Sequence Number 605 Incremental sequence counter modulo 2^32 of all IPFIX Data Records 606 sent in the current stream from the current Observation Domain by 607 the Exporting Process. Each SCTP Stream counts sequence numbers 608 separately, while all messages in a TCP connection or UDP 609 transport session are considered to be part of the same stream. 610 This value SHOULD be used by the Collecting Process to identify 611 whether any IPFIX Data Records have been missed. Template and 612 Options Template Records do not increase the Sequence Number. 614 Observation Domain ID 616 A 32-bit identifier of the Observation Domain that is locally 617 unique to the Exporting Process. The Exporting Process uses the 618 Observation Domain ID to uniquely identify to the Collecting 619 Process the Observation Domain that metered the Flows. It is 620 RECOMMENDED that this identifier also be unique per IPFIX Device. 621 Collecting Processes SHOULD use the Transport Session and the 622 Observation Domain ID field to separate different export streams 623 originating from the same Exporter. The Observation Domain ID 624 SHOULD be 0 when no specific Observation Domain ID is relevant for 625 the entire IPFIX Message, for example, when exporting the 626 Exporting Process Statistics, or in case of a hierarchy of 627 Collectors when aggregated Data Records are exported. 629 3.2. Field Specifier Format 631 Vendors need the ability to define proprietary Information Elements, 632 because, for example, they are delivering a pre-standards product, or 633 the Information Element is, in some way, commercially sensitive. 634 This section describes the Field Specifier format for both 635 IANA-registered Information Elements [IPFIX-IANA] and enterprise- 636 specific Information Elements. 638 The Information Elements are identified by the Information Element 639 identifier. When the Enterprise bit is set to 0, the corresponding 640 Information Element appears in [IPFIX-IANA], and the Enterprise 641 Number MUST NOT be present. When the Enterprise bit is set to 1, the 642 corresponding Information Element identifier identified an 643 enterprise-specific Information Element; the Enterprise Number MUST 644 be present. An example of this is shown in Section A.2.2. 646 The Field Specifier format is shown in Figure G. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |E| Information Element ident. | Field Length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Enterprise Number | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure G: Field Specifier Format 657 Where: 659 E 661 Enterprise bit. This is the first bit of the Field Specifier. If 662 this bit is zero, the Information Element Identifier identifies an 663 Information Element in [IPFIX-IANA], and the four-octet Enterprise 664 Number field MUST NOT be present. If this bit is one, the 665 Information Element identifier identifies an enterprise-specific 666 Information Element, and the Enterprise Number field MUST be 667 present. 669 Information Element identifier 671 A numeric value that represents the type of Information Element. 672 Refer to [IPFIX-IANA]. 674 Field Length 676 The length of the corresponding encoded Information Element, in 677 octets. Refer to [IPFIX-IANA]. The field length may be smaller 678 than that in [IPFIX-IANA] if the reduced size encoding is used 679 (see Section 6.2). The value 65535 is reserved for variable- 680 length Information Elements (see Section 7). 682 Enterprise Number 684 IANA enterprise number [PEN-IANA] of the authority defining the 685 Information Element identifier in this Template Record. 687 3.3. Set and Set Header Format 689 A Set is a generic term for a collection of records that have a 690 similar structure. There are three different types of Sets: Template 691 Sets, Options Template Sets, and Data Sets. Each of these Sets 692 consists of a Set Header and one or more records. The Set Format and 693 the Set Header Format are defined in the following sections. 695 3.3.1. Set Format 697 A Set has the format shown in Figure H. The record types can be 698 either Template Records, Options Template Records, or Data Records. 699 The record types MUST NOT be mixed within a Set. 701 +--------------------------------------------------+ 702 | Set Header | 703 +--------------------------------------------------+ 704 | record | 705 +--------------------------------------------------+ 706 | record | 707 +--------------------------------------------------+ 708 ... 709 +--------------------------------------------------+ 710 | record | 711 +--------------------------------------------------+ 712 | Padding (opt.) | 713 +--------------------------------------------------+ 715 Figure H: Set Format 717 Set Header 719 The Set Header Format is defined in Section 3.3.2. 721 Record 723 One of the record Formats: Template Record, Options Template 724 Record, or Data Record Format. 726 Padding 728 The Exporting Process MAY insert some padding octets, so that the 729 subsequent Set starts at an aligned boundary. For security 730 reasons, the padding octet(s) MUST be composed of zero (0) valued 731 octets. The padding length MUST be shorter than any allowable 732 record in this Set. If padding of the IPFIX Message is desired in 733 combination with very short records, then the padding Information 734 Element 'paddingOctets' can be used for padding records such that 735 their length is increased to a multiple of 4 or 8 octets. Because 736 Template Sets are always 4-octet aligned by definition, padding is 737 only needed in case of other alignments e.g., on 8-octet 738 boundaries. 740 3.3.2. Set Header Format 742 Every Set contains a common header. This header is defined in Figure 743 I. 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Set ID | Length | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure I: Set Header Format 753 Each Set Header field is exported in big-endian format. The fields 754 are defined as follows: 756 Set ID 758 Identifies the Set. A value of 2 is reserved for Template Sets. 759 A value of 3 is reserved for Options Template Sets. Values from 4 760 to 255 are reserved for future use. Values 256 and above are used 761 for Data Sets. The Set ID values of 0 and 1 are not used, for 762 historical reasons [RFC3954]. 764 Length 766 Total length of the Set, in octets, including the Set Header, all 767 records, and the optional padding. Because an individual Set MAY 768 contain multiple records, the Length value MUST be used to 769 determine the position of the next Set. 771 3.4. Record Format 773 IPFIX defines three record formats, defined in the next sections: the 774 Template Record Format, the Options Template Record Format, and the 775 Data Record Format. 777 3.4.1. Template Record Format 779 One of the essential elements in the IPFIX record format is the 780 Template Record. Templates greatly enhance the flexibility of the 781 record format because they allow the Collecting Process to process 782 IPFIX Messages without necessarily knowing the interpretation of all 783 Data Records. A Template Record contains any combination of 784 IANA-assigned and/or enterprise-specific Information Element 785 identifiers. 787 The format of the Template Record is shown in Figure J. It consists 788 of a Template Record Header and one or more Field Specifiers. The 789 definition of the Field Specifiers is given in Figure G above. 791 +--------------------------------------------------+ 792 | Template Record Header | 793 +--------------------------------------------------+ 794 | Field Specifier | 795 +--------------------------------------------------+ 796 | Field Specifier | 797 +--------------------------------------------------+ 798 ... 799 +--------------------------------------------------+ 800 | Field Specifier | 801 +--------------------------------------------------+ 803 Figure J: Template Record Format 805 The format of the Template Record Header is shown in Figure K. 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Template ID (> 255) | Field Count | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure K: Template Record Header Format 815 The Template Record Header Field Definitions are as follows: 817 Template ID 819 Each of the newly generated Template Records is given a unique 820 Template ID. This uniqueness is local to the Transport Session 821 and Observation Domain that generated the Template ID. Template 822 IDs 0-255 are reserved for Template Sets, Options Template Sets, 823 and other reserved Sets yet to be created. Template IDs of Data 824 Sets are numbered from 256 to 65535. There are no constraints 825 regarding the order of the Template ID allocation. As Exporting 826 Processes are free to allocate Template IDs as they see fit, 827 Collecting Processes MUST NOT assume anything about the contents 828 of a Template based on its Template ID alone. 830 Field Count 832 Number of fields in this Template Record. 834 The example in Figure L shows a Template Set with mixed IANA-assigned 835 and enterprise-specific Information Elements. It consists of a Set 836 Header, a Template Header, and several Field Specifiers. 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Set ID = 2 | Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Template ID = 256 | Field Count = N | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 |1| Information Element id. 1.1 | Field Length 1.1 | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Enterprise Number 1.1 | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |0| Information Element id. 1.2 | Field Length 1.2 | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | ... | ... | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |1| Information Element id. 1.N | Field Length 1.N | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Enterprise Number 1.N | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Template ID = 257 | Field Count = M | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |0| Information Element id. 2.1 | Field Length 2.1 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 |1| Information Element id. 2.2 | Field Length 2.2 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Enterprise Number 2.2 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | ... | ... | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |1| Information Element id. 2.M | Field Length 2.M | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Enterprise Number 2.M | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Padding (opt) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Figure L: Template Set Example 876 Information Element Identifiers 1.2 and 2.1 are defined by the IETF 877 (Enterprise bit = 0) and, therefore, do not need an Enterprise Number 878 to identify them. 880 3.4.2. Options Template Record Format 882 Thanks to the notion of scope, The Options Template Record gives the 883 Exporter the ability to provide additional information to the 884 Collector that would not be possible with Flow Records alone. 886 See Section 4 for specific Options Templates used for reporting 887 metadata about IPFIX Exporting and Metering Processes. 889 3.4.2.1. Scope 891 The scope, which is only available in the Options Template Set, gives 892 the context of the reported Information Elements in the Data 893 Records. 895 The scope is one or more Information Elements, specified in the 896 Options Template Record. Collecting Processes SHOULD support as 897 scope, at minimum, the observationDomainId, exportingProcessId, 898 meteringProcessId, templateId, lineCardId, exporterIPv4Address, 899 exporterIPv6Address, and ingressInterface Information Elements. The 900 IPFIX protocol doesn't prevent the use of any Information Elements 901 for scope. However, some Information Element types don't make sense 902 if specified as scope; for example, the counter Information Elements. 904 The IPFIX Message Header already contains the Observation Domain ID. 905 If not zero, this Observation Domain ID can be considered as an 906 implicit scope for the Data Records in the IPFIX Message. 908 Multiple Scope Fields MAY be present in the Options Template Record, 909 in which case, the composite scope is the combination of the scopes. 910 For example, if the two scopes are meteringProcessId and templateId, 911 the combined scope is this Template for this Metering Process. 913 3.4.2.2. Options Template Record Format 915 An Options Template Record contains any combination of IANA-assigned 916 and/or enterprise-specific Information Element identifiers. 918 The format of the Options Template Record is shown in Figure M. It 919 consists of an Options Template Record Header and one or more Field 920 Specifiers. The definition of the Field Specifiers is given in 921 Figure G above. 923 +--------------------------------------------------+ 924 | Options Template Record Header | 925 +--------------------------------------------------+ 926 | Field Specifier | 927 +--------------------------------------------------+ 928 | Field Specifier | 929 +--------------------------------------------------+ 930 ... 931 +--------------------------------------------------+ 932 | Field Specifier | 933 +--------------------------------------------------+ 935 Figure M: Options Template Record Format 937 The format of the Options Template Record Header is shown in Figure 938 N. 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Template ID (> 255) | Field Count | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Scope Field Count | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure N: Options Template Record Header Format 950 The Options Template Record Header Field Definitions are as follows: 952 Template ID 954 Template ID of this Options Template Record. As they identify Data 955 Sets, Options Template IDs share a number space with Template IDs. 956 As with Templates, since Exporting Processes are free to allocate 957 Options Template IDs as they see fit, Collecting Processes MUST 958 NOT assume anything about the contents of an Options Template 959 based on its Template ID alone. 961 Field Count 963 Number of all fields in this Options Template Record, including 964 the Scope Fields. 966 Scope Field Count 968 Number of scope fields in this Options Template Record. The Scope 969 Fields are normal Fields except that they are interpreted as scope 970 at the Collector. The Scope Field Count MUST NOT be zero. 972 The example in Figure O shows an Options Template Set with mixed 973 IANA-assigned and enterprise-specific Information Elements. It 974 consists of a Set Header, a Options Template Header, and several 975 Field Specifiers. 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Set ID = 3 | Length | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Template ID = 258 | Field Count = N + M | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Scope Field Count = N |0| Scope 1 Infor. Element Id. | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Scope 1 Field Length |0| Scope 2 Infor. Element Id. | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Scope 2 Field Length | ... | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | ... |1| Scope N Infor. Element Id. | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Scope N Field Length | Scope N Enterprise Number ... 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Option 1 Field Length | Option 1 Enterprise Number ... 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 ... Option 1 Enterprise Number | ... | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | ... |0| Option M Infor. Element Id. | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Option M Field Length | Padding (optional) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Figure O: Options Template Set Example 1007 3.4.3. Data Record Format 1009 The Data Records are sent in Data Sets. The format of the Data 1010 Record is shown in Figure P. It consists only of one or more Field 1011 Values. The Template ID to which the Field Values belong is encoded 1012 in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". 1014 +--------------------------------------------------+ 1015 | Field Value | 1016 +--------------------------------------------------+ 1017 | Field Value | 1018 +--------------------------------------------------+ 1019 ... 1020 +--------------------------------------------------+ 1021 | Field Value | 1022 +--------------------------------------------------+ 1024 Figure P: Data Record Format 1026 Note that Field Values do not necessarily have a length of 16 bits. 1027 Field Values are encoded according to their data type specified in 1028 [RFC5102bis]. 1030 Interpretation of the Data Record format can be done only if the 1031 Template Record corresponding to the Template ID is available at the 1032 Collecting Process. 1034 The example in Figure Q shows a Data Set. It consists of a Set Header 1035 and several Field Values. 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Set ID = Template ID | Length | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Record 1 - Field Value 1 | Record 1 - Field Value 2 | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Record 1 - Field Value 3 | ... | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Record 2 - Field Value 1 | Record 2 - Field Value 2 | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Record 2 - Field Value 3 | ... | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Record 3 - Field Value 1 | Record 3 - Field Value 2 | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Record 3 - Field Value 3 | ... | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | ... | Padding (optional) | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Figure Q: Data Set, containing Data Records 1059 4. Specific Reporting Requirements 1061 Some specific Options Templates and Options Template Records are 1062 necessary to provide extra information about the Flow Records and 1063 about the Metering Process. 1065 The Options Template and Options Template Records defined in these 1066 subsections, which impose some constraints on the Metering Process 1067 and Exporting Process implementations, MAY be implemented. If 1068 implemented, the specific Options Templates SHOULD be implemented as 1069 specified in these subsections. 1071 The minimum set of Information Elements is always specified in these 1072 Specific IPFIX Options Templates. Nevertheless, extra Information 1073 Elements may be used in these specific Options Templates. 1075 The Collecting Process MUST check the possible combinations of 1076 Information Elements within the Options Template Records to correctly 1077 interpret the following Options Templates. 1079 4.1. The Metering Process Statistics Options Template 1081 The Metering Process Statistics Options Template specifies the 1082 structure of a Data Record for reporting Metering Process statistics. 1083 It SHOULD contain the following Information Elements; see [IPFIX- 1084 IANA] for their definitions 1085 (scope) observationDomainId 1086 This Information Element MUST be defined as a 1087 Scope Field, and MUST be present unless the 1088 Observation Domain ID of the enclosing 1089 Message is non-zero. 1091 (scope) meteringProcessId 1092 This Information Element MUST be defined as a 1093 Scope Field. 1095 exportedMessageTotalCount 1097 exportedFlowRecordTotalCount 1099 exportedOctetTotalCount 1101 The Exporting Process SHOULD export the Data Record specified by the 1102 Metering Process Statistics Options Template on a regular basis or 1103 based on some export policy. This periodicity or export policy 1104 SHOULD be configurable. 1106 Note that if several Metering Processes are available on the Exporter 1107 Observation Domain, the Information Element meteringProcessId MUST be 1108 specified as an additional Scope Field. 1110 4.2. The Metering Process Reliability Statistics Options Template 1112 The Metering Process Reliability Options Template specifies the 1113 structure of a Data Record for reporting lack of reliability in the 1114 Metering Process. It SHOULD contain the following Information 1115 Elements defined in [IPFIX-IANA]: 1117 (scope) observationDomainId 1118 This Information Element MUST be defined as a 1119 Scope Field, and MUST be present unless the 1120 Observation Domain ID of the enclosing 1121 Message is non-zero. 1123 (scope) meteringProcessId 1124 This Information Element MUST be defined as a 1125 Scope Field. 1127 ignoredPacketTotalCount 1129 ignoredOctetTotalCount 1130 time first packet ignored 1131 The timestamp of the first packet that was 1132 ignored by the Metering Process. For this 1133 timestamp, any of the following timestamp 1134 Information Elements can be used: 1135 observationTimeSeconds, 1136 observationTimeMilliseconds, 1137 observationTimeMicroseconds, or 1138 observationTimeNanoseconds. 1140 time last packet ignored 1141 The timestamp of the last packet that was 1142 ignored by the Metering Process. For this 1143 timestamp, any of the following timestamp 1144 Information Elements can be used: 1145 observationTimeSeconds, 1146 observationTimeMilliseconds, 1147 observationTimeMicroseconds, or 1148 observationTimeNanoseconds. 1150 The Exporting Process SHOULD export the Data Record specified by the 1151 Metering Process Reliability Statistics Options Template on a regular 1152 basis or based on some export policy. This periodicity or export 1153 policy SHOULD be configurable. 1155 Note that if several Metering Processes are available on the Exporter 1156 Observation Domain, the Information Element meteringProcessId MUST be 1157 specified as an additional Scope Field. 1159 Since the Metering Process Reliability Option Template contains two 1160 identical timestamp Information Elements, and since the order of the 1161 Information Elements in the Template Records is not guaranteed, the 1162 Collecting Process interprets the time interval of ignored packets as 1163 the range between the two values; see Section 5.2 for wraparound 1164 considerations. 1166 4.3. The Exporting Process Reliability Statistics Options Template 1168 The Exporting Process Reliability Options Template specifies the 1169 structure of a Data Record for reporting lack of reliability in the 1170 Exporting process. It SHOULD contain the following Information 1171 Elements defined in [IPFIX-IANA]: 1173 (scope) Exporting Process ID 1174 The identifier of the Exporting Process for 1175 which reliability is reported. Any of the 1176 exporterIPv4Address, exporterIPv6Address, or 1177 exportingProcessId Information Elements can be 1178 used for this field. This Information Element 1179 MUST be defined as a Scope Field. 1181 notSentFlowTotalCount 1183 notSentPacketTotalCount 1185 notSentOctetTotalCount 1187 time first flow dropped 1188 The time at which the first Flow Record was 1189 dropped by the Exporting Process. For this 1190 timestamp, any of the following timestamp can be 1191 used: observationTimeSeconds, 1192 observationTimeMilliseconds, 1193 observationTimeMicroseconds, or 1194 observationTimeNanoseconds. 1196 time last flow dropped 1197 The time at which the last Flow Record was 1198 dropped by the Exporting Process. For this 1199 timestamp, any of the following timestamp can be 1200 used: observationTimeSeconds, 1201 observationTimeMilliseconds, 1202 observationTimeMicroseconds, or 1203 observationTimeNanoseconds. 1205 The Exporting Process SHOULD export the Data Record specified by the 1206 Exporting Process Reliability Statistics Options Template on a 1207 regular basis or based on some export policy. This periodicity or 1208 export policy SHOULD be configurable. 1210 Since the Exporting Process Reliability Option Template contains two 1211 identical timestamp Information Elements, and since the order of the 1212 Information Elements in the Template Records is not guaranteed, the 1213 Collecting Process interprets the time interval of ignored packets as 1214 the range between the two values; see Section 5.2 for wraparound 1215 considerations. 1217 4.4. The Flow Keys Options Template 1219 The Flow Keys Options Template specifies the structure of a Data 1220 Record for reporting the Flow Keys of reported Flows. A Flow Keys 1221 Data Record extends a particular Template Record that is referenced 1222 by its templateId identifier. The Template Record is extended by 1223 specifying which of the Information Elements contained in the 1224 corresponding Data Records describe Flow properties that serve as 1225 Flow Keys of the reported Flow. 1227 The Flow Keys Options Template SHOULD contain the following 1228 Information Elements that are defined in [IPFIX-IANA]: 1230 (scope) templateId This Information Element MUST be defined as a 1231 Scope Field. 1233 flowKeyIndicator Bitmap with the positions of the Flow Keys in 1234 the Data Records. 1236 5. Timing Considerations 1238 5.1 IPFIX Message Header Export Time and Flow Record Time 1240 The IPFIX Message Header Export Time field is the time at which the 1241 IPFIX Message Header leaves the Exporter, using the same encoding as 1242 the dateTimeSeconds abstract data type [RFC5102bis], i.e., expressed 1243 in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded 1244 as an unsigned 32-bit integer. 1246 Certain time-related Information Elements may be expressed as an 1247 offset from this Export Time. For example, Data Records requiring a 1248 microsecond precision can export the flow start and end times with 1249 the flowStartMicroseconds and flowEndMicroseconds Information 1250 Elements, which encode the absolute time in microseconds in terms of 1251 the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An 1252 alternate solution is to export the flowStartDeltaMicroseconds and 1253 flowEndDeltaMicroseconds Information Elements in the Data Record, 1254 which respectively report the flow start and end time as negative 1255 offsets from the Export Time, as an unsigned 32-bit integer. This 1256 latter solution lowers the export bandwidth requirement, saving four 1257 bytes per timestamp, while increasing the load on the Exporter, as 1258 the Exporting Process must calculate the flowStartDeltaMicroseconds 1259 and flowEndDeltaMicroseconds of every single Data Record before 1260 exporting the IPFIX Message. 1262 It must be noted that timestamps based on the Export Time impose some 1263 time constraints on the Data Records contained within the IPFIX 1264 Message. In the example of flowStartDeltaMicroseconds and 1265 flowEndDeltaMicroseconds Information Elements, the Data Record can 1266 only contain records with timestamps within 71 minutes of the Export 1267 Time. Otherwise, the 32-bit counter would not be sufficient to 1268 contain the flow start time offset. 1270 5.2 Supporting Timestamp Wraparound 1272 The dateTimeSeconds abstract data type [RFC5102bis] and the Export 1273 Time Message Header field (Section 3.1) are encoded as 32-bit 1274 unsigned integers, expressed as seconds since the UNIX epoch, 1 1275 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will 1276 wrap around on 7 February 2106 at 06:28:16 UTC. 1278 In order to support continued use of the IPFIX Protocol beyond this 1279 date, Exporting Processes SHOULD export dateTimeSeconds values and 1280 the Export Time Message Header field as the number of seconds since 1281 the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting 1282 Processes SHOULD use the current date, or other contextual 1283 information, to properly interpret dateTimeSeconds values and the 1284 Export Time Message Header field. 1286 There are similar considerations for the NTP-based 1287 dateTimeMicroseconds and dateTimeNanoseconds abstract data types 1288 [RFC5102bis]. Exporting Processes SHOULD export dateTimeMicroseconds 1289 and dateTimeNanoseconds values as if the NTP Era [RFC5905] is 1290 implicit; Collecting Processes SHOULD use the current date, or other 1291 contextual information, to determine the NTP Era in order to properly 1292 interpret dateTimeMicroseconds and dateTimeNanoseconds values in 1293 received Data Records. 1295 The dateTimeMilliseconds abstract data type will wrap around in 1296 approximately 500 billion years; the specification of the behavior of 1297 this abstract data type after that time is left as a subject of a 1298 future revision of this specification. 1300 The long-term storage of files [RFC5655] for archival purposes is 1301 affected by timestamp wraparound, as the use of the current date to 1302 interpret timestamp values in files stored on the order of multiple 1303 decades in the past may lead to incorrect values; therefore, it is 1304 RECOMMENDED that such files be stored with contextual information to 1305 assist in the interpretation of these timestamps. 1307 6. Linkage with the Information Model 1309 As with values in the IPFIX Message Header and Set Header, values of 1310 all Information Elements [RFC5102bis], except for those of the string 1311 and octetArray data types, are encoded in canonical format in network 1312 byte order (also known as big-endian byte ordering). 1314 6.1. Encoding of IPFIX Data Types 1316 The following sections define the encoding of the data types 1317 specified in [RFC5102bis]. 1319 6.1.1. Integral Data Types 1321 Integral data types -- octet, signed8, unsigned16, signed16, 1322 unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded 1323 using the default canonical format in network byte order. Signed 1324 Integral data types are represented in two's complement notation. 1326 6.1.2. Address Types 1328 Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be 1329 encoded the same way as the integral data types, as six, four, and 1330 sixteen octets in network byte order, respectively. 1332 6.1.3. float32 1334 The float32 data type MUST be encoded as an IEEE single-precision 1335 32-bit floating point-type, as specified in [IEEE.754.1985], in 1336 network byte order. 1338 6.1.4. float64 1340 The float64 data type MUST be encoded as an IEEE double-precision 64- 1341 bit floating point-type, as specified in [IEEE.754.1985], in network 1342 byte order. 1344 6.1.5. boolean 1346 The boolean data type is specified according to the TruthValue in 1347 [RFC2579]. It is encoded as a single-octet integer, as in Section 1348 6.1.1., with the value 1 for true and a value 2 for false. Every 1349 other value is undefined. 1351 6.1.6. string and octetArray 1353 The data type string represents a finite length string of valid 1354 characters of the Unicode character encoding set. The string data 1355 type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as 1356 an array of zero or more octets using an Information Element of fixed 1357 or variable length. The data type octetArray has no encoding rules; 1358 it represents a raw array of zero or more octets, with the 1359 interpretation of the octets defined in the Information Element 1360 definition. 1362 The data type dateTimeSeconds is an unsigned 32-bit integer in 1363 network byte order containing the number of seconds since the UNIX 1364 epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 1365 dateTimeSeconds is encoded identically to the IPFIX Message Header 1366 Export Time field. It can represent dates between 1 January 1970 and 1367 7 February 2106 without wraparound; see section 5.2 for wraparound 1368 considerations. 1370 6.1.8. dateTimeMilliseconds 1372 The data type dateTimeMilliseconds is an unsigned 64-bit integer in 1373 network byte order, containing the number of milliseconds since the 1374 UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It 1375 can represent dates beginning on 1 January 1970 for approximately the 1376 next 500 billion years without wraparound. 1378 6.1.9 dateTimeMicroseconds 1380 The data type dateTimeMicroseconds is a 64-bit field encoded 1381 according to the NTP Timestamp format as defined in section 6 of 1382 [RFC5905]. This field is made up of two unsigned 32-bit integers in 1383 network byte order, Seconds and Fraction. The Seconds field is the 1384 number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. 1385 The Fraction field is the fractional number of seconds in units of 1386 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1387 dates beginning between 1 January 1900 and 8 February 2036 in the 1388 current NTP Era; see section 5.2 for wraparound considerations. 1390 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1391 identical encoding. The dateTimeMicroseconds data type is intended 1392 only to represent timestamps of microsecond precision. Therefore, the 1393 bottom 11 bits of the fraction field SHOULD be zero and MUST be 1394 ignored for all Information Elements of this data type (as 2^11 x 233 1395 picoseconds = .477 microseconds). 1397 6.1.10 dateTimeNanoseconds 1399 The data type dateTimeNanoseconds is a 64-bit field encoded according 1400 to the NTP Timestamp format as defined in section 6 of [RFC5905]. 1401 This field is made up of two unsigned 32-bit integers in network byte 1402 order, Seconds and Fraction. The Seconds field is the number of 1403 seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The 1404 Fraction field is the fractional number of seconds in units of 1405 1/(2^32) seconds (approximately 233 picoseconds). It can represent 1406 dates beginning between 1 January 1900 and 8 February 2036 in the 1407 current NTP Era; see section 5.2 for wraparound considerations. 1409 Note that dateTimeMicroseconds and dateTimeNanoseconds share an 1410 identical encoding. There is no restriction on the interpretation of 1411 the Fraction field for the dateTimeNanoseconds data type. 1413 6.2. Reduced Size Encoding 1415 Information Elements encoded as signed, unsigned, or float data types 1416 MAY be encoded using fewer octets than those implied by their type in 1417 the information model definition, based on the assumption that the 1418 smaller size is sufficient to carry any value the Exporter may need 1419 to deliver. This reduces the network bandwidth requirement between 1420 the Exporter and the Collector. Note that the Information Element 1421 definitions [IPFIX-IANA] always define the maximum encoding size. 1423 For instance, the information model defines octetDeltaCount as an 1424 unsigned64 type, which would require 64 bits. However, if the 1425 Exporter will never locally encounter the need to send a value larger 1426 than 4294967295, it may chose to send the value instead as an 1427 unsigned32. 1429 This behavior is indicated by the Exporter by specifying a size in 1430 the Template with a smaller length than that associated with the 1431 assigned type of the Information Element. In the example above, the 1432 Exporter would place a length of 4 versus 8 in the Template. 1434 If reduced size encoding MAY be be applied to the following integer 1435 types: unsigned64, signed64, unsigned32, signed32, unsigned16, and 1436 signed16. The signed versus unsigned property of the reported value 1437 MUST be preserved. The reduction in size can be to any number of 1438 octets smaller than the original type if the data value still fits, 1439 i.e., so that only leading zeroes are dropped. For example, an 1440 unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). 1442 Reduced size encoding MAY be used to reduce float64 to float32. The 1443 float32 not only has a reduced number range, but due to the smaller 1444 mantissa, is also less precise. In this case, the float64 would be 1445 reduced in size to 4 octets. 1447 Reduced size encoding MUST NOT be applied to any other data type 1448 defined in [RFC5102bis] that implies a fixed length, as these types 1449 either have internal structure (such as ipv4Address or 1450 dateTimeMicroseconds) or restricted ranges that are not suitable for 1451 reduced length encoding (such as dateTimeMilliseconds). 1453 Information Elements of type octetArray and string may be exported 1454 using any length, subject to restrictions on length specific to each 1455 Information Element, as noted in that Information Element's 1456 description. 1458 7. Variable-Length Information Element 1460 The IPFIX Template mechanism is optimized for fixed-length 1461 Information Elements [RFC5102bis]. Where an Information Element has 1462 a variable length, the following mechanism MUST be used to carry the 1463 length information for both the IETF and proprietary Information 1464 Elements. 1466 In the Template Set, the Information Element Field Length is recorded 1467 as 65535. This reserved length value notifies the Collecting Process 1468 that length of the Information Element will be carried in the 1469 Information Element content itself. 1471 In most cases, the length of the Information Element will be less 1472 than 255 octets. The following length-encoding mechanism optimizes 1473 the overhead of carrying the Information Element length in this 1474 majority case. The length is carried in the octet before the 1475 Information Element, as shown in Figure R. 1477 0 1 2 3 1478 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 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Length (< 255)| Information Element | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | ... continuing as needed | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Figure R: Variable-Length Information Element (length < 255 octets) 1487 The length may also be encoded into 3 octets before the Information 1488 element allowing the length of the Information Element to be greater 1489 than or equal to 255 octets. In this case, first octet of the Length 1490 field MUST be 255, and the length is carried in the second and third 1491 octets, as shown in Figure S. 1493 0 1 2 3 1494 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 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | 255 | Length (0 to 65535) | IE | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | ... continuing as needed | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 Figure S: Variable-Length Information Element (length 0 to 65535 1502 octets) 1503 The octets carrying the length (either the first or the first three 1504 octets) MUST NOT be included in the length of the Information 1505 Element. 1507 8. Template Management 1509 This section describes the management of Templates and Options 1510 Templates at the Exporting and Collecting Processes. The goal of 1511 Template management is to ensure, to the extent possible, that the 1512 Exporting Process and Collecting Process have a consistent view of 1513 the Templates and Options Templates used to encode and decode the 1514 Records sent from the Exporting Process to the Collecting Process. 1515 Achieving this goal is complicated somewhat by two factors: 1. the 1516 need to support the reuse of Template IDs within a Transport Session 1517 and 2. the need to support unreliable transmission for templates when 1518 UDP is used as the transport protocol for IPFIX Messages. 1520 The Template Management mechanisms defined in this section apply to 1521 IPFIX Message export on any supported Transport Protocol. Additional 1522 considerations specific to SCTP and UDP transport are given in 1523 sections 8.3 and 8.4, respectively. 1525 The Exporting Process assigns and maintains the Template IDs per 1526 Transport Session for the Exporter's Observation Domains. A newly 1527 created Template Record is assigned an unused Template ID by the 1528 Exporting Process. The Collecting Process MUST store all received 1529 Template Record information for the duration of each Transport 1530 Session until reuse or withdrawal as in section 8.1, except as noted 1531 in section 8.4, so that it can interpret the corresponding Data 1532 Records that are received in subsequent Data Sets. The Collecting 1533 Process MUST NOT assume that the Template IDs from a given Exporting 1534 Process refer to the same Templates as they did in previous Transport 1535 Sessions from the same Exporting Process; a Collecting Process MUST 1536 NOT use Templates from one Transport Session to decode Data Sets in a 1537 subsequent Transport Session. 1539 If a specific Information Element is required by a Template, but is 1540 not present in observed packets, the Exporting Process MAY choose to 1541 export Flow Records without this Information Element in a Data Record 1542 described by a new Template. 1544 If an Information Element is required more than once in a Template, 1545 the different occurrences of this Information Element SHOULD follow 1546 the logical order of their treatments by the Metering Process. For 1547 example, if a selected packet goes through two hash functions, and if 1548 the two hash values are sent within a single Template, the first 1549 occurrence of the hash value should belong to the first hash function 1550 in the Metering Process. For example, when exporting the two source 1551 IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address 1552 Information Element occurrence should be the IPv4 address of the 1553 outer header, while the second occurrence should be the address of 1554 the inner header. Collecting processes MUST properly handle Templates 1555 with multiple identical Information Elements. 1557 The Exporting Process SHOULD transmit the Template Set and Options 1558 Template Set in advance of any Data Sets that use that (Options) 1559 Template ID, to help ensure that the Collector has the Template 1560 Record before receiving the first Data Record. Data Records that 1561 correspond to a Template Record MAY appear in the same and/or 1562 subsequent IPFIX Message(s). However, a Collecting Process MUST NOT 1563 assume that the Data Set and the associated Template Set (or Options 1564 Template Set) are exported in the same IPFIX Message. 1566 Though a Collecting Process normally receives Template Records from 1567 the Exporting Process before receiving Data Records, this is not 1568 always the case, e.g. in case of reordering or Collecting Process 1569 restart over UDP. In these cases, thee Collecting Process MAY buffer 1570 Data Records for which it has no Templates to wait for Template 1571 Records describing them; however, note that in the presence of 1572 Template withdrawal and redefinition (Section 8.1) this may lead to 1573 incorrect interpretation of Data Records. 1575 Different Observation Domains from the same Transport Session MAY use 1576 the same Template ID value to refer to different Templates; 1577 Collecting Processes MUST properly handle this case. 1579 Options Templates and Templates which are related or interdependent 1580 (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent 1581 together in the same IPFIX Message. 1583 8.1. Template Withdrawal and Redefinition 1585 Since a Template may have a lifetime at the Exporting Process 1586 independent of the Transport Session, IPFIX provides a mechanism for 1587 the withdrawal of templates and for the reuse of template IDs. This 1588 mechanism does not apply when UDP is used to transport IPFIX 1589 messages; for this case, see Section 8.4. 1591 Templates that will not be used further by an Exporting Process MAY 1592 be withdrawn by sending a Template Withdrawal. After receiving a 1593 Template Withdrawal, a Collecting Process MUST stop using the 1594 Template to interpret subsequently-exported Data Sets. 1596 A Template Withdrawal consists of a Template Record for the Template 1597 ID to be with a Field Count of 0. The format of a Template Withdrawal 1598 is shown in Figure T. 1600 0 1 2 3 1601 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 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Set ID = (2 or 3) | Length = 16 | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Template ID N | Field Count = 0 | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Template ID ... | Field Count = 0 | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Template ID M | Field Count = 0 | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 Figure T: Template Withdrawal Format 1614 The Set ID field MUST contain the value 2 for Template Set Withdrawal 1615 and the value 3 for Options Template Set Withdrawal. Multiple 1616 Template IDs MAY be withdrawn with a single Template Withdrawal, in 1617 that case, padding MAY be used. 1619 Template Withdrawals MAY appear interleaved with Template Sets, 1620 Options Template Sets, and Data Sets within an IPFIX Message. In this 1621 case, the Withdrawals and Templates shall be taken to take effect in 1622 the order in which they appear in the Message. An Exporting Process 1623 SHOULD NOT send a Template Withdrawal until sufficient time has 1624 elapsed to allow receipt and processing of and Data Records described 1625 by the withdrawn Templates; see Section 8.2 on sequencing of Template 1626 management actions. 1628 The end of a Transport Session implicitly withdraws all the Templates 1629 used within the Transport Session, and Templates must be resent 1630 during subsequent Transport Sessions between an Exporting Process and 1631 Collecting Process. All Templates for a given Observation Domain MAY 1632 also be withdrawn using an All Templates Withdrawal, shown in Figure 1633 U. All Options Templates for a given observation Domain MAY likewise 1634 be withdrawn using an All Options Templates Withdrawal, shown in 1635 Figure 3. 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Set ID = 2 | Length = 8 | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Template ID = 2 | Field Count = 0 | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 Figure U: All Templates Withdrawal Set Format 1646 0 1 2 3 1647 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 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Set ID = 3 | Length = 8 | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Template ID = 3 | Field Count = 0 | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Figure V: All Options Templates Withdrawal Set Format 1656 Template IDs MAY be reused for new Templates by sending a new 1657 Template Record or Options Template Record for a given Template ID 1658 after withdrawing the Template. 1660 If a Collecting Process receives a Template Withdrawal for a Template 1661 or Options Template it does not presently have stored, this indicates 1662 a malfunctioning or improperly-implemented Exporting Process. The 1663 continued receipt and interpretation of Data Records is still 1664 possible, but it MUST ignore the Template Withdrawal and SHOULD log 1665 the error. 1667 If a Collecting Process receives a new Template Record or Options 1668 Template Record for an already-allocated Template ID, and that 1669 Template or Options Template is identical to the already-received 1670 Template or Options Template, it SHOULD log the retransmission; 1671 however, this is not an error condition, as it does not affect the 1672 interpretation of data records. 1674 If a Collecting Process receives a new Template Record or Options 1675 Template Record for an already-allocated Template ID, and that 1676 Template or Options Template is different from the already-received 1677 Template or Options Template, this indicates a malfunctioning or 1678 improperly-implemented Exporting Process. The continued receipt and 1679 unambiguous interpretation of Data Records for this Template ID is no 1680 longer possible, the Collecting Process SHOULD log the error; further 1681 Collecting Process actions are out of scope of this specification. 1683 8.2 Sequencing Template Management Actions 1685 Since there is no guarantee of the ordering of exported IPFIX 1686 Messages across SCTP Streams or over UDP, an Exporting Process MUST 1687 sequence all template management actions (i.e., Template Records 1688 defining new templates and Template Withdrawals withdrawing them) 1689 using the Export Time field in the IPFIX Message Header. 1691 An Exporting Process MUST NOT export a Data Set described by a new 1692 Template in an IPFIX Message with an Export Time before the Export 1693 Time of the IPFIX Message containing that Template. If a new Template 1694 and a Data Set described by it appear in the same IPFIX Message, the 1695 Template Set containing the Template MUST appear before the Data Set 1696 in the Message. 1698 An Exporting Process MUST NOT export any Data Sets described by a 1699 withdrawn Template in IPFIX Messages with an Export Time after the 1700 Export Time of the IPFIX Message containing the Template Withdrawal 1701 withdrawing that Template. 1703 Put another way, a Template describes Data Records contained in IPFIX 1704 Messages with an Export Time between the Export Time of the IPFIX 1705 Message containing the Template Record and the end of the Transport 1706 Session, inclusive, if that Template is not subsequently withdrawn. 1708 If a Template is subsequently withdrawn, then that Template describes 1709 Data Records contained in IPFIX Messages with an Export Time between 1710 the Export Time of the IPFIX Message containing the Template Record 1711 and the Export Time of the IPFIX Message containing the Template 1712 Withdrawal, inclusive. 1714 Note that, even if sent in-order, IPFIX Messages containing Template 1715 management actions could arrive at the Collecting Process out-of- 1716 order, i.e. if sent via UDP or via different SCTP streams. Template 1717 Withdrawals and subsequent reuse of Template IDs, in particular, can 1718 significantly complicate the problem of determining Template 1719 lifetimes at the Collecting Process. Therefore, Collecting Processes 1720 MAY implement a buffer to handle out-of-order Template management 1721 events; this buffer, if implemented, SHOULD be configurable to impart 1722 a delay on the order of the maximum reordering delay experienced at 1723 the Collecting Process. 1725 8.3. Additional considerations for Template Management over SCTP 1727 Template Sets and Options Template Sets MAY be sent on any SCTP 1728 stream. Data Sets sent on a given SCTP stream MAY be represented by 1729 Template Records exported on any SCTP stream. 1731 Template Sets and Options Template Sets MUST be sent reliably and in 1732 order. 1734 Template Withdrawals MAY be sent on any SCTP stream. Template 1735 Withdrawals MUST be sent reliably, using SCTP-ordered delivery. 1736 Template IDs MAY be reused by sending a Template Withdrawal and/or a 1737 new Template Record on a different SCTP stream than the stream on 1738 which the original Template was sent. 1740 Additional Template Management considerations are given in [RFC6526], 1741 which specifies an extension to explicitly link Templates with SCTP 1742 streams. In exchange for more restrictive rules on the assignment of 1743 Template Records to SCTP streams, this extension allows fast, 1744 reliable reuse of Template IDs and estimation of Data Record loss per 1745 Template. 1747 8.4. Additional considerations for Template Management over UDP 1749 Since UDP provides no method for reliable transmission of Templates, 1750 Exporting Processes using UDP as the Transport Protocol MUST 1751 periodically retransmit each active Template at regular intervals. 1752 The template retransmission interval MUST be configurable, as via the 1753 the templateRefreshTimeout and optionsTemplateRefreshTimeout defined 1754 in [RFC6728]. Default settings for these values are deployment- and 1755 application-specific. 1757 Before exporting any Data Records described by a given Template 1758 Record or Options Template Record, especially in the case of Template 1759 ID reuse as in section 8.1, the Exporting Process SHOULD send 1760 multiple copies of the Template Record in separate IPFIX Message, in 1761 order to help ensure the Collecting Process has received it. 1763 In order to minimize resource requirements for templates which have 1764 expired at the Exporting Process, the Collecting Process MAY 1765 associate a lifetime with each Template received in a UDP Transport 1766 Session. Templates not refreshed by the Exporting Process within the 1767 lifetime can then be discarded by the Collecting Process. The 1768 template lifetime at the Collecting Process MAY be exposed by a 1769 configuration parameter, or MAY be derived from observation of the 1770 interval of periodic Template retransmissions from the Exporting 1771 Process. In this latter case, the Template lifetime SHOULD default to 1772 at least 3 times the observed retransmission rate. 1774 Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting 1775 Processes exporting via UDP, and MUST be ignored by Collecting 1776 Processes collecting via UDP. Template IDs MAY be reused by Exporting 1777 Processes by simply allowing the old Template to expire and exporting 1778 a new Template for the Template ID. 1780 When a Collecting Process receives a new Template Record or Options 1781 Template Record via UDP for an already-allocated Template ID, and 1782 that Template or Options Template is identical to the already- 1783 received Template or Options Template, it SHOULD NOT log the 1784 retransmission, as this is the normal operation of Template refresh 1785 over UDP. 1787 When a Collecting Process receives a new Template Record or Options 1788 Template Record for an already-allocated Template ID, and that 1789 Template or Options Template is different from the already-received 1790 Template or Options Template, the Collecting Process MUST replace the 1791 Template or Options Template for that Template ID with the newly- 1792 received Template or Options Template. This is the normal operation 1793 of Template ID reuse over UDP. 1795 As template IDs are unique per UDP session and per Observation 1796 Domain, at any given time, the Collecting Process SHOULD maintain the 1797 following for all the current Template Records and Options Template 1798 Records: . 1801 9. The Collecting Process's Side 1803 This section describes the handling of the IPFIX Protocol at the 1804 Collecting Process common to all Transport Protocols. Additional 1805 considerations for SCTP and UDP are given in Sections 9.1 and 9.2 1806 respectively. Template management at Collecting Processes is covered 1807 in Section 8. 1809 The Collecting Process MUST listen for association requests / 1810 connections to start new Transport Sessions from the Exporting 1811 Process. 1813 The Collecting Process MUST note the Information Element identifier 1814 of any Information Element that it does not understand and MAY 1815 discard that Information Element from received Data Records. 1817 The Collecting Process MUST accept padding in Data Records and 1818 Template Records. The padding size is the Set Length minus the size 1819 of the Set Header (4 octets for the Set ID and the Set Length), 1820 modulo the Record size deduced from the Template Record. 1822 The IPFIX protocol has a Sequence Number field in the Export header 1823 that increases with the number of IPFIX Data Records in the IPFIX 1824 Message. The Collecting Process SHOULD detect out-of-sequence, 1825 dropped, or duplicate IPFIX Messages using this the Sequence Number. 1826 If it supports this mechanism, the Collecting Process SHOULD log such 1827 Messages, as these could indicate resource exhaustion at the 1828 Exporting Process or the Collecting Process, an Exporting Process 1829 reset, packet loss due to congestion between the Exporting Process 1830 and the Collecting Process, or message injection. 1832 If the Collecting Process receives a malformed IPFIX Message it MUST 1833 discard the IPFIX Message and SHOULD log the error. A malformed IPFIX 1834 Message is one that cannot be interpreted due to nonsensical length 1835 values (e.g., a variable length Information Element longer than its 1836 enclosing Set, a Set longer than its enclosing Message, a Message 1837 shorter than an IPFIX Message Header) or a reserved Version value 1838 (which may indicate a future version of IPFIX is being used for 1839 export, but practically occurs most often when non-IPFIX data is sent 1840 to an IPFIX Collecting Process, as the Message Header Version field 1841 serves as a de facto magic number for IPFIX). Note that non-zero Set 1842 padding does not constitute a malformed IPFIX Message. 1844 9.1. Additional considerations for SCTP Collecting Processes 1846 The Exporting Process requests a number of streams to use for export 1847 at association setup time. An Exporting Process MAY request and 1848 support more than one stream per SCTP association. 1850 9.2. Additional considerations for UDP Collecting Processes 1852 A Transport Session for IPFIX Messages transported over UDP is 1853 defined from the point of view of the Exporting Process, and roughly 1854 corresponds to the time during which a given Exporting Process sends 1855 IPFIX messages over UDP to a given Collecting Process. Since this is 1856 difficult to detect at the Collecting Process, the Collecting Process 1857 MAY expire all Transport Session state after no IPFIX Messages are 1858 received from a given Exporting Process within a given Transport 1859 Session during a configurable idle timeout. 1861 The Collecting Process SHOULD accept Data Records without the 1862 associated Template Record (or other definitions) required to decode 1863 the Data Record. If the Template Records (or other definitions such 1864 as Common Properties) have not been received at the time Data Records 1865 are received, the Collecting Process MAY store the Data Records for a 1866 short period of time and decode them after the Template Records (or 1867 other definitions) are received. The short period of time MUST be 1868 lower than the lifetime of definitions associated with identifiers 1869 considered unique within the UDP session. Note that this mechanism 1870 may lead to incorrectly interpreted records in the presence of 1871 Template ID reuse 1873 10. Transport Protocol 1875 The IPFIX Protocol Specification has been designed to be transport 1876 protocol independent. Note that the Exporter can export to multiple 1877 Collecting Processes using independent transport protocols. 1879 The IPFIX Message Header 16-bit Length field limits the length of an 1880 IPFIX Message to 65535 octets, including the header. A Collecting 1881 Process MUST be able to handle IPFIX Message lengths of up to 65535 1882 octets. 1884 10.1. Transport Compliance and Transport Usage 1886 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 1887 MUST be implemented by all compliant implementations. UDP [UDP] MAY 1888 also be implemented by compliant implementations. TCP [TCP] MAY also 1889 be implemented by compliant implementations. 1891 SCTP SHOULD be used in deployments where Exporters and Collectors are 1892 communicating over links that are susceptible to congestion. PR-SCTP 1893 is capable of providing any required degree of reliability. 1895 TCP MAY be used in deployments where Exporters and Collectors 1896 communicate over links that are susceptible to congestion, but SCTP 1897 is preferred due to its ability to limit back pressure on Exporters 1898 and its message versus stream orientation. 1900 UDP MAY be used, although it is not a congestion-aware protocol. 1901 However, in this case the IPFIX traffic between Exporter and 1902 Collector MUST be separately contained or provisioned to minimize the 1903 risk of congestion-related loss. 1905 By default, the Collecting Process listens for connections on SCTP, 1906 TCP, and/or UDP port 4739. By default, the Collecting Process 1907 listens for secure connections on SCTP, TCP, and/or UDP port 4740 1908 (refer to the Security Considerations section). By default, the 1909 Exporting Process attempts to connect to one of these ports. It MUST 1910 be possible to configure both the Exporting and Collecting Processes 1911 to use different SCTP ports that the default. 1913 10.2. SCTP 1915 This section describes how IPFIX is transported over SCTP [RFC4960] 1916 using the PR-SCTP [RFC3758] extension. 1918 10.2.1. Congestion Avoidance 1920 The SCTP transport protocol provides the required level of congestion 1921 avoidance by design. 1923 SCTP detects congestion in the end-to-end path between the IPFIX 1924 Exporting Process and the IPFIX Collecting Process, and limits the 1925 transfer rate accordingly. When an IPFIX Exporting Process has 1926 records to export, but detects that transmission by SCTP is 1927 temporarily impossible, it can either wait until sending is possible 1928 again, or it can decide to drop the record. In the latter case, the 1929 dropped export data SHOULD be accounted for, so that the amount of 1930 dropped export data can be reported using the mechanism in Section 1931 4.3. 1933 10.2.2. Reliability 1935 The SCTP transport protocol is by default reliable, but has the 1936 capability to deliver messages with partial reliability [RFC3758]. 1938 Using reliable SCTP messages for the IPFIX export is not in itself a 1939 guarantee that all Data Records will be delivered. If there is 1940 congestion on the link from the Exporting Process to the Collecting 1941 Process, or if a significant number of retransmissions are required, 1942 the send queues on the Exporting Process may fill up; the Exporting 1943 Process MAY either suspend, export, or discard the IPFIX Messages. 1944 If Data Records are discarded the IPFIX Sequence Numbers used for 1945 export MUST reflect the loss of data. 1947 10.2.3. MTU 1949 SCTP provides the required IPFIX Message fragmentation service based 1950 on path MTU discovery. 1952 10.2.4. Association Establishment and Shutdown 1954 The IPFIX Exporting Process initiates an SCTP association with the 1955 IPFIX Collecting Process. The Exporting Process MAY establish more 1956 than one association (connection "bundle" in SCTP terminology) to the 1957 Collecting Process. 1959 An Exporting Process MAY support more than one active association to 1960 different Collecting Processes (including the case of different 1961 Collecting Processes on the same host). 1963 When an Exporting Process is shut down, it SHOULD shut down the SCTP 1964 association. 1966 When a Collecting Process no longer wants to receive IPFIX Messages, 1967 it SHOULD shut down its end of the association. The Collecting 1968 Process SHOULD continue to receive and process IPFIX Messages until 1969 the Exporting Process has closed its end of the association. 1971 When a Collecting Process detects that the SCTP association has been 1972 abnormally terminated, it MUST continue to listen for a new 1973 association establishment. 1975 When an Exporting Process detects that the SCTP association to the 1976 Collecting Process is abnormally terminated, it SHOULD try to 1977 re-establish the association. 1979 Association timeouts SHOULD be configurable. 1981 10.2.5. Failover 1983 If the Collecting Process does not acknowledge the attempt by the 1984 Exporting Process to establish an association, the Exporting Process 1985 should retry using the SCTP exponential backoff feature. The 1986 Exporter MAY log an alarm if the time to establish the association 1987 exceeds a specified threshold, configurable on the Exporter. 1989 If Collecting Process failover is supported by the Exporting Process, 1990 a second SCTP association MAY be opened in advance. 1992 10.2.6. Streams 1994 An Exporting Process MAY request more than one SCTP stream per 1995 association. Each of these streams may be used for the transmission 1996 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 1997 Template Sets. 1999 Depending on the requirements of the application, the Exporting 2000 Process may send Data Sets with full or partial reliability, using 2001 ordered or out-of-order delivery, over any SCTP stream established 2002 during SCTP Association setup. 2004 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 2005 per Section 4 of the PR-SCTP [RFC3758] specification when using 2006 partial reliability to transmit IPFIX Messages containing only Data 2007 Sets. 2009 However, Exporting Processes SHOULD mark such IPFIX Messages for 2010 retransmission for as long as resource or other constraints allow. 2012 10.3. UDP 2014 This section describes how IPFIX is transported over UDP [UDP]. 2016 10.3.1. Congestion Avoidance 2018 UDP has no integral congestion-avoidance mechanism. Its use over 2019 congestion-sensitive network paths is therefore not recommended. UDP 2020 MAY be used in deployments where Exporters and Collectors always 2021 communicate over dedicated links that are not susceptible to 2022 congestion, i.e., links that are over-provisioned compared to the 2023 maximum export rate from the Exporters. 2025 10.3.2. Reliability 2027 UDP is not a reliable transport protocol, and cannot guarantee 2028 delivery of messages. IPFIX Messages sent from the Exporting Process 2029 to the Collecting Process using UDP may therefore be lost. UDP MUST 2030 NOT be used unless the application can tolerate some loss of IPFIX 2031 Messages. 2033 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 2034 Data Records by looking at the discontinuities in the IPFIX Sequence 2035 Number. In the case of UDP, the IPFIX Sequence Number contains the 2036 total number of IPFIX Data Records sent for the UDP Transport Session 2037 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 2038 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 2039 by tracking the Sequence Number. Templates sent from the Exporting 2040 Process to the Collecting Process using UDP as a transport MUST be 2041 re-sent at regular intervals, in case previous copies were lost. 2043 Exporting Processes exporting IPFIX Messages via UDP MUST include a 2044 valid UDP checksum. 2046 10.3.3. MTU 2048 The maximum size of exported messages MUST be configured such that 2049 the total packet size does not exceed the path MTU. If the path MTU 2050 is unknown, a maximum packet size of 512 octets SHOULD be used. 2052 10.3.4. Session Establishment and Shutdown 2054 As UDP is a connectionless protocol, there is no real session 2055 establishment or shutdown for IPFIX over UDP. An Exporting Process 2056 starts sending IPFIX Messages to a Collecting Process at one point in 2057 time, and stops sending them at another point in time. This leads to 2058 some complications in template management, which are outlined in 2059 Section 8.4 above. 2061 10.3.5. Failover and Session Duplication 2063 Because UDP is not a connection-oriented protocol, the Exporting 2064 Process is unable to determine from the transport protocol that the 2065 Collecting Process is no longer able to receive the IPFIX Messages. 2066 Therefore, it cannot invoke a failover mechanism. However, the 2067 Exporting Process MAY duplicate the IPFIX Message to several 2068 Collecting Processes. 2070 10.4. TCP 2072 The IPFIX Exporting Process initiates a TCP connection to the 2073 Collecting Process. By default, the Collecting Process listens for 2074 connections on TCP port 4739. By default, the Collecting Process 2075 listens for secure connections on TCP port 4740 (refer to the 2076 Security Considerations section). By default, the Exporting Process 2077 tries to connect to one of these ports. It MUST be possible to 2078 configure both the Exporting Process and the Collecting Process to 2079 use a different TCP port. 2081 An Exporting Process MAY support more than one active connection to 2082 different Collecting Processes (including the case of different 2083 Collecting Processes on the same host). 2085 The Exporter MAY log an alarm if the time to establish the connection 2086 exceeds a specified threshold, configurable on the Exporter. 2088 10.4.1. Congestion Avoidance 2090 TCP controls the rate at which data can be sent from the Exporting 2091 Process to the Collecting Process, using a mechanism that takes into 2092 account both congestion in the network and the capabilities of the 2093 receiver. 2095 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2096 Messages at the rate that the Metering Process generates them, either 2097 because of congestion in the network or because the Collecting 2098 Process cannot handle IPFIX Messages fast enough. As long as 2099 congestion is transient, the Exporting Process can buffer IPFIX 2100 Messages for transmission. But such buffering is necessarily limited, 2101 both because of resource limitations and because of timeliness 2102 requirements, so ongoing and/or severe congestion may lead to a 2103 situation where the Exporting Process is blocked. 2105 When an Exporting Process has Data Records to export but the 2106 transmission buffer is full, and it wants to avoid blocking, it can 2107 decide to drop some Data Records. The dropped Data Records MUST be 2108 accounted for, so that the number of lost records can later be 2109 reported as in Section 4.3. 2111 10.4.2. Reliability 2113 TCP ensures reliable delivery of data from the Exporting Process to 2114 the Collecting Process. 2116 10.4.3. MTU 2118 As TCP offers a stream service instead of a datagram or sequential 2119 packet service, IPFIX Messages transported over TCP are instead 2120 separated using the Length field in the IPFIX Message Header. The 2121 Exporting Process can choose any valid length for exported IPFIX 2122 Messages, as TCP handles segmentation. 2124 However, if an Exporting Process exports data from multiple 2125 Observation Domains, it should be careful to choose IPFIX Message 2126 lengths appropriately to minimize head-of-line blocking between 2127 different Observation Domains. Multiple TCP connections MAY be used 2128 to avoid head-of-line blocking between different Observation Domains. 2130 10.4.4. Connection Establishment, Shutdown, and Restart 2132 The IPFIX Exporting Process initiates a TCP connection to the 2133 Collecting Process. An Exporting Process MAY support more than one 2134 active connection to different Collecting Processes (including the 2135 case of different Collecting Processes on the same host). 2137 The Exporter MAY log an alarm if the time to establish the connection 2138 exceeds a specified threshold, configurable on the Exporter. 2140 When an Exporting Process is shut down, it SHOULD shut down the TCP 2141 connection. 2143 When a Collecting Process no longer wants to receive IPFIX Messages, 2144 it SHOULD close its end of the connection. The Collecting Process 2145 SHOULD continue to read IPFIX Messages until the Exporting Process 2146 has closed its end. 2148 When a Collecting Process detects that the TCP connection to the 2149 Exporting Process has terminated abnormally, it MUST continue to 2150 listen for a new connection. 2152 When an Exporting Process detects that the TCP connection to the 2153 Collecting Process has terminated abnormally, it SHOULD try to 2154 re-establish the connection. Connection timeouts and retry schedules 2155 SHOULD be configurable. In the default configuration, an Exporting 2156 Process MUST NOT attempt to establish a connection more frequently 2157 than once per minute. 2159 10.4.5. Failover 2161 If the Collecting Process does not acknowledge an attempt by the 2162 Exporting Process to establish a connection, TCP will automatically 2163 retry connection establishment using exponential backoff. 2165 If Collecting Process failover is supported by the Exporting Process, 2166 a second TCP connection MAY be opened in advance. 2168 11. Security Considerations 2170 The security considerations for the IPFIX protocol have been derived 2171 from an analysis of potential security threats, as discussed in the 2172 "Security Considerations" section of IPFIX requirements [RFC3917]. 2173 The requirements for IPFIX security are as follows: 2175 1. IPFIX must provide a mechanism to ensure the confidentiality of 2176 IPFIX data transferred from an Exporting Process to a Collecting 2177 Process, in order to prevent disclosure of Flow Records 2178 transported via IPFIX. 2180 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2181 data transferred from an Exporting Process to a Collecting 2182 Process, in order to prevent the injection of incorrect data or 2183 control information (e.g., Templates) into an IPFIX Message 2184 stream. 2186 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2187 and Exporting Processes, to prevent the collection of data from an 2188 unauthorized Exporting Process or the export of data to an 2189 unauthorized Collecting Process. 2191 Because IPFIX can be used to collect information for network 2192 forensics and billing purposes, attacks designed to confuse, disable, 2193 or take information from an IPFIX collection system may be seen as a 2194 prime objective during a sophisticated network attack. 2196 An attacker in a position to inject false messages into an IPFIX 2197 Message stream can either affect the application using IPFIX (by 2198 falsifying data), or the IPFIX Collecting Process itself (by 2199 modifying or revoking Templates, or changing options); for this 2200 reason, IPFIX Message integrity is important. 2202 The IPFIX Messages themselves may also contain information of value 2203 to an attacker, including information about the configuration of the 2204 network as well as end-user traffic and payload data, so care must be 2205 taken to confine their visibility to authorized users. When an 2206 Information Element containing end-user payload information is 2207 exported, it SHOULD be transmitted to the Collecting Process using a 2208 means that secures its contents against eavesdropping. Suitable 2209 mechanisms include the use of either a direct point-to-point 2210 connection or the use of an encryption mechanism. It is the 2211 responsibility of the Collecting Process to provide a satisfactory 2212 degree of security for this collected data, including, if necessary, 2213 anonymization of any reported data. 2215 11.1. Applicability of TLS and DTLS 2217 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2218 Security (DTLS) [RFC6347] were designed to provide the 2219 confidentiality, integrity, and authentication assurances required by 2220 the IPFIX protocol, without the need for pre-shared keys. 2222 With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC6347] 2223 MUST be implemented. If UDP is selected as the IPFIX transport 2224 protocol, DTLS [RFC6347] MUST be implemented. If TCP is selected as 2225 the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. 2227 Note that DTLS is selected as the security mechanism for SCTP. 2228 Though TLS bindings to SCTP are defined in [RFC3436], they require 2229 all communication to be over reliable, bidirectional streams, and 2230 require one TLS connection per stream. This arrangement is not 2231 compatible with the rationale behind the choice of SCTP as an IPFIX 2232 transport protocol. 2234 Note that using DTLS [RFC6347] has a vulnerability, i.e., a true man 2235 in the middle may attempt to take data out of an association and fool 2236 the sender into thinking that the data was actually received by the 2237 peer. In generic TLS for SCTP (and/or TCP), this is not possible. 2238 This means that the removal of a message may become hidden from the 2239 sender or receiver. Another vulnerability of using SCTP with DTLS is 2240 that someone could inject SCTP control information to shut down the 2241 SCTP association, effectively generating a loss of IPFIX Messages if 2242 those are buffered outside of the SCTP association. Techniques such 2243 as [RFC6083] could be used to overcome these vulnerabilities. 2245 When using DTLS over SCTP, the Exporting Process MUST ensure that 2246 each IPFIX Message is sent over the same SCTP stream that would be 2247 used when sending the same IPFIX Message directly over SCTP. Note 2248 that DTLS may send its own control messages on stream 0 with full 2249 reliability; however, this will not interfere with the processing of 2250 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2251 consumes its own control messages before passing IPFIX Messages up to 2252 the application layer. 2254 When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] 2255 SHOULD be used, especially on long-lived Transport Sessions, to 2256 ensure that the association remains active. 2258 11.2. Usage 2260 The IPFIX Exporting Process initiates the communication to the IPFIX 2261 Collecting Process, and acts as a TLS or DTLS client according to 2262 [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a 2263 TLS or DTLS server. The DTLS client opens a secure connection on the 2264 SCTP port 4740 of the DTLS server if SCTP is selected as the 2265 transport protocol. The TLS client opens a secure connection on the 2266 TCP port 4740 of the TLS server if TCP is selected as the transport 2267 protocol. The DTLS client opens a secure connection on the UDP port 2268 4740 of the DTLS server if UDP is selected as the transport 2269 protocol. 2271 11.3. Authentication 2273 IPFIX Exporting Processes and IPFIX Collecting Processes are 2274 identified by the fully qualified domain name of the interface on 2275 which IPFIX Messages are sent or received, for purposes of X.509 2276 client and server certificates as in [RFC5280]. 2278 To prevent man-in-the-middle attacks from impostor Exporting or 2279 Collecting Processes, the acceptance of data from an unauthorized 2280 Exporting Process, or the export of data to an unauthorized 2281 Collecting Process, strong mutual authentication via asymmetric keys 2282 MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and 2283 Collecting Processes MUST verify the identity of its peer against its 2284 authorized certificates, and MUST verify that the peer's certificate 2285 matches its fully qualified domain name, or, in the case of SCTP, the 2286 fully qualified domain name of one of its endpoints. 2288 The fully qualified domain name used to identify an IPFIX Collecting 2289 Process or Exporting Process may be stored either in a subjectAltName 2290 extension of type dNSName, or in the most specific Common Name field 2291 of the Subject field of the X.509 certificate. If both are present, 2292 the subjectAltName extension is given preference. 2294 Internationalized domain names (IDN) in either the subjectAltName 2295 extension of type dNSName or the most specific Common Name field of 2296 the Subject field of the X.509 certificate MUST be encoded using 2297 Punycode [RFC3492] as described in [RFC5891], "Conversion 2298 Operations". 2300 11.4. Protection against DoS Attacks 2302 An attacker may mount a denial-of-service (DoS) attack against an 2303 IPFIX collection system either directly, by sending large amounts of 2304 traffic to a Collecting Process, or indirectly, by generating large 2305 amounts of traffic to be measured by a Metering Process. 2307 Direct DoS attacks can also involve state exhaustion, whether at the 2308 transport layer (e.g., by creating a large number of pending 2309 connections), or within the IPFIX Collecting Process itself (e.g., by 2310 sending Flow Records pending Template or scope information, a large 2311 amount of Options Template Records, etc.). 2313 SCTP mandates a cookie-exchange mechanism designed to defend against 2314 SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN 2315 cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be 2316 used by any Collecting Process accepting TCP connections. DTLS also 2317 provides cookie exchange to protect against DTLS server state 2318 exhaustion. 2320 The reader should note that there is no way to prevent fake IPFIX 2321 Message processing (and state creation) for UDP & SCTP communication. 2322 The use of TLS and DTLS can obviously prevent the creation of fake 2323 states, but they are themselves prone to state exhaustion attacks. 2324 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2325 DTLS (like limiting the number of new TLS or DTLS session per second 2326 to a sensible number). 2328 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2329 at which new connections or associations will be opened by the 2330 Collecting Process, the rate at which IPFIX Messages will be accepted 2331 by the Collecting Process, and adaptively limiting the amount of 2332 state kept, particularly records waiting on Templates. These rate 2333 and state limits MAY be provided by a Collecting Process; if 2334 provided, the limits SHOULD be user configurable. 2336 Additionally, an IPFIX Collecting Process can eliminate the risk of 2337 state exhaustion attacks from untrusted nodes by requiring TLS or 2338 DTLS mutual authentication, causing the Collecting Process to accept 2339 IPFIX Messages only from trusted sources. 2341 With respect to indirect denial of service, the behavior of IPFIX 2342 under overload conditions depends on the transport protocol in use. 2343 For IPFIX over TCP, TCP congestion control would cause the flow of 2344 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2345 system. SCTP improves upon this situation somewhat, as some IPFIX 2346 Messages would continue to be received by the Collecting Process due 2347 to the avoidance of head-of-line blocking by SCTP's multiple streams 2348 and partial reliability features, possibly affording some visibility 2349 of the attack. The situation is similar with UDP, as some datagrams 2350 may continue to be received at the Collecting Process, effectively 2351 applying sampling to the IPFIX Message stream, implying that some 2352 forensics may be left. 2354 To minimize IPFIX Message loss under overload conditions, some 2355 mechanism for service differentiation could be used to prioritize 2356 IPFIX traffic over other traffic on the same link. Alternatively, 2357 IPFIX Messages can be transported over a dedicated network. In this 2358 case, care must be taken to ensure that the dedicated network can 2359 handle the expected peak IPFIX Message traffic. 2361 11.5. When DTLS or TLS Is Not an Option 2363 The use of DTLS or TLS might not be possible in some cases due to 2364 performance issues or other operational concerns. 2366 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2367 and Collecting Processes can fall back on using IP source addresses 2368 to authenticate their peers. A policy of allocating Exporting 2369 Process and Collecting Process IP addresses from specified address 2370 ranges, and using ingress filtering to prevent spoofing, can improve 2371 the usefulness of this approach. Again, completely segregating IPFIX 2372 traffic on a dedicated network, where possible, can improve security 2373 even further. In any case, the use of open Collecting Processes 2374 (those that will accept IPFIX Messages from any Exporting Process 2375 regardless of IP address or identity) is discouraged. 2377 Modern TCP and SCTP implementations are resistant to blind insertion 2378 attacks (see [RFC4960], [RFC6528]); however, UDP offers no such 2379 protection. For this reason, IPFIX Message traffic transported via 2380 UDP and not secured via DTLS SHOULD be protected via segregation to a 2381 dedicated network. 2383 11.6. Logging an IPFIX Attack 2385 IPFIX Collecting Processes MUST detect potential IPFIX Message 2386 insertion or loss conditions by tracking the IPFIX Sequence Number, 2387 and SHOULD provide a logging mechanism for reporting out-of-sequence 2388 messages. Note that an attacker may be able to exploit the handling 2389 of out-of-sequence messages at the Collecting Process, so care should 2390 be taken in handling these conditions. For example, a Collecting 2391 Process that simply resets the expected Sequence Number upon receipt 2392 of a later Sequence Number could be temporarily blinded by deliberate 2393 injection of later Sequence Numbers. 2395 IPFIX Exporting and Collecting Processes SHOULD log any connection 2396 attempt that fails due to authentication failure, whether due to 2397 being presented an unauthorized or mismatched certificate during TLS 2398 or DTLS mutual authentication, or due to a connection attempt from an 2399 unauthorized IP address when TLS or DTLS is not in use. 2401 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2402 SCTP association reset or TCP connection reset. 2404 11.7. Securing the Collector 2406 The security of the Collector and its implementation is important to 2407 achieve overall security. However, it is outside the scope of this 2408 document. 2410 12. IANA Considerations 2412 IPFIX Messages use two fields with assigned values. These are the 2413 IPFIX Version Number, indicating which version of the IPFIX Protocol 2414 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2415 the type for each set of information within an IPFIX Message. 2417 The Information Elements used by IPFIX, and sub-registries of 2418 Information Element values, are managed by IANA [IPFIX-IANA], as are 2419 the Private Enterprise Numbers used by enterprise-specific 2420 Information Elements [PEN-IANA]. This document makes no changes to 2421 these registries. 2423 The IPFIX Version Number value of 0x000a (10) is reserved for the 2424 IPFIX protocol specified in this document. Set ID values of 0 and 1 2425 are not used, for historical reasons [RFC3954]. The Set ID value of 2426 2 is reserved for the Template Set. The Set ID value of 3 is 2427 reserved for the Options Template Set. All other Set ID values from 2428 4 to 255 are reserved for future use. Set ID values above 255 are 2429 used for Data Sets. 2431 New assignments in either IPFIX Version Number or IPFIX Set ID 2432 assignments require a Standards Action [RFC5226], i.e., they are to 2433 be made via Standards Track RFCs approved by the IESG. 2435 [NOTE for IANA: Please change references in the IPFIX Information 2436 Element Registry to RFC5101 to point to this document, instead.] 2438 Appendix A. IPFIX Encoding Examples 2440 This appendix, which is a not a normative reference, contains IPFIX 2441 encoding examples. 2443 Let's consider the example of an IPFIX Message composed of a 2444 Template Set, a Data Set (which contains three Data Records), an 2445 Options Template Set and a Data Set (which contains 2 Data Records 2446 related to the previous Options Template Record). 2448 IPFIX Message: 2450 +--------+------------------------------------------. . . 2451 | | +--------------+ +------------------+ 2452 |Message | | Template | | Data | 2453 | Header | | Set | | Set | . . . 2454 | | | (1 Template) | | (3 Data Records) | 2455 | | +--------------+ +------------------+ 2456 +--------+------------------------------------------. . . 2458 . . .-------------------------------------------+ 2459 +------------------+ +------------------+ | 2460 | Options | | Data | | 2461 . . . | Template Set | | Set | | 2462 | (1 Template) | | (2 Data Records) | | 2463 +------------------+ +------------------+ | 2464 . . .-------------------------------------------+ 2466 A.1. Message Header Example 2468 The Message Header is composed of: 2469 0 1 2 3 2470 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 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Version = 0x000a | Length = 152 | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Export Time | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Sequence Number | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | Observation Domain ID | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 A.2. Template Set Examples 2483 A.2.1. Template Set Using IETF-Specified Information Elements 2485 We want to report the following Information Elements: 2487 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], 2488 with a length of 4 octets 2490 - The IPv4 destination IP address: destinationIPv4Address in 2491 [IPFIX-IANA], with a length of 4 octets 2493 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2494 [IPFIX-IANA], with a length of 4 octets 2496 - The number of packets of the Flow: packetDeltaCount in 2497 [IPFIX-IANA], with a length of 4 octets 2499 - The number of octets of the Flow: octetDeltaCount in 2500 [IPFIX-IANA], with a length of 4 octets 2502 Therefore, the Template Set will be composed of the following: 2504 0 1 2 3 2505 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 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | Set ID = 2 | Length = 28 octets | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Template ID 256 | Field Count = 5 | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 |0| sourceIPv4Address = 8 | Field Length = 4 | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 |0| destinationIPv4Address = 12 | Field Length = 4 | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 |0| packetDeltaCount = 2 | Field Length = 4 | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 |0| octetDeltaCount = 1 | Field Length = 4 | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 A.2.2. Template Set Using Enterprise-Specific Information Elements 2524 We want to report the following Information Elements: 2526 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], with 2527 a length of 4 octets 2529 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2530 IANA], with a length of 4 octets 2532 - An enterprise-specific Information Element representing 2533 proprietary information, with a type of 15 and a length of 4 2535 - The number of packets of the Flow: packetDeltaCount in [IPFIX- 2536 IANA], with a length of 4 octets 2538 - The number of octets of the Flow: octetDeltaCount in [IPFIX-IANA], 2539 with a length of 4 octets 2541 Therefore, the Template Set will be composed of the following: 2543 0 1 2 3 2544 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 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | Set ID = 2 | Length = 32 octets | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 | Template ID 257 | Field Count = 5 | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 |0| sourceIPv4Address = 8 | Field Length = 4 | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 |0| destinationIPv4Address = 12 | Field Length = 4 | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 |1| Information Element Id. = 15| Field Length = 4 | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | Enterprise number | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 |0| packetDeltaCount = 2 | Field Length = 4 | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 |0| octetDeltaCount = 1 | Field Length = 4 | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 A.3. Data Set Example 2565 In this example, we report the following three Flow Records: 2567 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2568 | | | Number | Number 2569 ------------------------------------------------------------------ 2570 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2571 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2572 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2574 0 1 2 3 2575 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 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | Set ID = 256 | Length = 64 | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | 192.0.2.12 | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | 192.0.2.254 | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | 192.0.2.1 | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | 5009 | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | 5344385 | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | 192.0.2.27 | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | 192.0.2.23 | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | 192.0.2.2 | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | 748 | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | 388934 | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | 192.0.2.56 | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | 192.0.2.65 | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | 192.0.2.3 | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | 5 | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | 6534 | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 Note that padding is not necessary in this example. 2612 A.4. Options Template Set Examples 2614 A.4.1. Options Template Set Using IETF-Specified Information Elements 2616 Per line card (the router being composed of two line cards), we want 2617 to report the following Information Elements: 2619 - Total number of IPFIX Messages: exportedMessageTotalCount [IPFIX- 2620 IANA], with a length of 2 octets 2622 - Total number of exported Flows: exportedFlowRecordTotalCount 2623 [IPFIX-IANA], with a length of 2 octets 2625 The line card, which is represented by the lineCardId Information 2626 Element [IPFIX-IANA], is used as the Scope Field. 2628 Therefore, the Options Template Set will be: 2630 0 1 2 3 2631 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 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | Set ID = 3 | Length = 24 | 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Template ID 258 | Field Count = 3 | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Scope Field Count = 1 |0| lineCardId = 141 | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Field Length = 2 | Padding | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 A.4.2. Options Template Set Using Enterprise-Specific Information 2647 Elements 2649 Per line card (the router being composed of two line cards), we want 2650 to report the following Information Elements: 2652 - Total number of IPFIX Messages: exportedMessageTotalCount 2653 [IPFIX-IANA], with a length of 2 octets 2655 - An enterprise-specific number of exported Flows, with a type of 2656 42 and a length of 4 octets 2658 The line card, which is represented by the lineCardId Information 2659 Element [IPFIX-IANA], is used as the Scope Field. 2661 The format of the Options Template Set is as follows: 2663 0 1 2 3 2664 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 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | Set ID = 3 | Length = 28 | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | Template ID 259 | Field Count = 3 | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | Scope Field Count = 1 |0| lineCardId = 141 | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 | Field Length = 2 |1|Information Element Id. = 42 | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | Field Length = 4 | Enterprise number ... 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 ... Enterprise number | Padding | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2683 In this example, we want to export the same information as in the 2684 example in Section A.4.1: 2686 - Total number of IPFIX Messages: exportedMessageTotalCount 2687 [IPFIX-IANA], with a length of 2 octets 2689 - Total number of exported Flows: exportedFlowRecordTotalCount 2690 [IPFIX-IANA], with a length of 2 octets 2692 But this time, the information pertains to a proprietary scope, 2693 identified by enterprise-specific Information Element number 123. 2695 The format of the Options Template Set is now as follows: 2697 0 1 2 3 2698 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 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | Set ID = 3 | Length = 28 | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | Template ID 260 | Field Count = 3 | 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 | Scope 1 Field Length = 4 | Enterprise Number ... 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | Field Length = 2 | Padding | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 A.4.4. Data Set Using an Enterprise-Specific Scope 2717 In this example, we report the following two Data Records: 2719 Enterprise field 123 | IPFIX Message | Exported Flow Records 2720 ------------------------------------------------------------------- 2721 1 | 345 | 10201 2722 2 | 690 | 20402 2724 0 1 2 3 2725 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 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Set ID = 260 | Length = 20 | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | 1 | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | 345 | 10201 | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | 2 | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | 690 | 20402 | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 A.5. Variable-Length Information Element Examples 2740 A.5.1. Example of Variable-Length Information Element with Length 2741 Inferior to 255 Octets 2743 0 1 2 3 2744 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 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | 5 | 5 octet Information Element | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | | 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 A.5.2. Example of Variable-Length Information Element with 3 Octet 2752 Length Encoding 2754 0 1 2 3 2755 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 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 | 255 | 1000 | IE ... | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | 1000 octet Information Element | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2761 : ... : 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | ... IE | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 References 2768 Normative References 2770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2771 Requirement Levels", BCP 14, RFC 2119, March 1997. 2773 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2774 Layer Security over Stream Control Transmission 2775 Protocol", RFC 3436, December 2002. 2777 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of 2778 Unicode for Internationalized Domain Names in 2779 Applications (IDNA)", RFC 3492, March 2003. 2781 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2782 10646", RFC 3629, November 2003. 2784 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2785 Conrad, "Stream Control Transmission Protocol (SCTP) 2786 Partial Reliability Extension", RFC 3758, May 2004. 2788 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 2789 Protocol", RFC 4960, September 2007. 2791 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2792 an IANA Considerations Section in RFCs", BCP 26, RFC 2793 5226, May 2008. 2795 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2796 Security (TLS) Protocol Version 1.2", RFC 5246, August 2797 2008. 2799 [RFC5280] Cooper, D., Santesson, S., Farrell, S. Boeyen, S. 2800 Housley, R., and W. Polk, "Internet X.509 Public Key 2801 Infrastructure Certificate and Certificate Revocation 2802 List (CRL) Profile", RFC 5280, April 2008. 2804 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 2805 W. Kasch, "Network Time Protocol Version 4: Protocol 2806 and Algorithms Specification", RFC 5905, June 2010 2808 [RFC5891] J. Klensin, "Internationalized Domain Names in 2809 Applications (IDNA): Protocol", RFC 5891, August 2010. 2811 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 2812 Layer Security Version 1.2", RFC 6347, January 2012. 2814 [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., 2815 "Transport Layer Security (TLS) and Datagram Transport 2816 Layer Security (DTLS) Heartbeat Extension", RFC 6520, 2817 February 2012. 2819 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2820 RFC 793, September 1981. 2822 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2823 August 1980. 2825 [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. 2826 Meyer, "Information Model for IP Flow Information 2827 Export", draft-claise-ipfix-information-model- 2828 rfc5102bis-01.txt, Work in Progress, October 2011. 2830 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 2832 Informative References 2834 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2835 "Textual Conventions for SMIv2", STD 58, RFC 2579, 2836 April 1999. 2838 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2839 Jacobson, "RTP: A Transport Protocol for Real-Time 2840 Applications", STD 64, RFC 3550, July 2003. 2842 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2843 "Requirements for IP Flow Information Export (IPFIX)", 2844 RFC 3917, October 2004. 2846 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 2847 Export Version 9", RFC 3954, October 2004. 2849 [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP 2850 Flow Information Export (IPFIX)", RFC 5103, January 2851 2008. 2853 [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP 2854 Flow Information Export (IPFIX) Protocol for the 2855 Exchange of IP Traffic Flow Information", RFC 5101, 2856 January 2008. 2858 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 2859 Flow Information Export (IPFIX) Implementation 2860 Guidelines", RFC5153, April 2008 2862 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 2863 Quittek, "Architecture for IP Flow Information 2864 Export", RFC5470, March 2009. 2866 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 2867 "IP Flow Information Export (IPFIX) Applicability", 2868 RFC5472, March 2009. 2870 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 2871 for IP Flow Information Export (IPFIX) Testing", 2872 RFC5471, March 2009 2874 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2875 Redundancy in IP Flow Information Export (IPFIX) and 2876 Packet Sampling (PSAMP) Reports", RFC5473, March 2009 2878 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2879 "Exporting Type Information for IP Flow Information 2880 Export (IPFIX) Information Elements", RFC 5610, July 2881 2009. 2883 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2884 Wagner, "Specification of the IP Flow Information 2885 Export (IPFIX) File Format", RFC 5655, October 2009. 2887 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 2888 Transport Layer Security (DTLS) for Stream Control 2889 Transmission Protocol (SCTP)", RFC6083, January 2011. 2891 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 2892 "Export of Structured Data in IP Flow Information 2893 Export (IPFIX)", RFC6313, July 2011. 2895 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 2896 "IP Flow Information Export (IPFIX) Mediation: 2897 Framework", RFC6183, April 2011. 2899 [RFC6526] Claise, B., Aitken, P., Johnson, A. and G. Muenz, 2900 "IPFIX Export per SCTP Stream", RFC 6526, March 2012. 2902 [RFC6528] Gont, F. and S. Bellovin, "Defending Against Sequence 2903 Number Attacks", RFC 6528, February 2012. 2905 [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 2906 "Definitions of Managed Objects for IP Flow 2907 Information Export", RFC 6615, June 2012. 2909 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration 2910 Data Model for IPFIX and PSAMP", RFC 6728, October 2911 2012. 2913 [PEN-IANA] IANA Private Enterprise Numbers registry 2914 http://www.iana.org/assignments/enterprise-numbers. 2916 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 2917 Technology - Portable Operating System Interface, 2918 IEEE, 2008. 2920 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 2921 "Standard for Binary Floating-Point Arithmetic", IEEE 2922 Standard 754, August 1985. 2924 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 2925 "Specification of the Protocol for IPFIX Mediations", 2926 draft-ietf-ipfix-mediation-protocol-02, Work in 2927 Progress, July 2012. 2929 Acknowledgments 2931 We would like to thank the following persons: Ganesh Sadasivan for 2932 his significant contribution during the initial phases of the 2933 protocol specification; Juergen Quittek for the coordination job 2934 within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and 2935 Andrew Johnson for the thorough reviews; Randall Stewart and Peter 2936 Lei for their SCTP expertise and contributions; Martin Djernaes for 2937 the first essay on the SCTP section; Michael Behringer and Eric 2938 Vyncke for their advice and knowledge in security; Michael Tuexen for 2939 his help regarding the DTLS section; Elisa Boschi for her 2940 contribution regarding the improvement of SCTP sections; Mark 2941 Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter 2942 Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul 2943 Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical 2944 reviews and feedback. 2946 Authors' Addresses 2948 Benoit Claise (Ed.) 2949 Cisco Systems 2950 De Kleetlaan 6a b1 2951 1831 Diegem 2952 Belgium 2954 Phone: +32 2 704 5622 2955 EMail: bclaise@cisco.com 2957 Brian Trammell (Ed.) 2958 Swiss Federal Institute of Technology Zurich 2959 Gloriastrasse 35 2960 8092 Zurich 2961 Switzerland 2963 Phone: +41 44 632 70 13 2964 EMail: trammell@tik.ee.ethz.ch 2965 Stewart Bryant 2966 Cisco Systems, Inc. 2967 250, Longwater, 2968 Green Park, 2969 Reading, RG2 6GB, 2970 United Kingdom 2972 Phone: +44 (0)20 8824-8828 2973 EMail: stbryant@cisco.com 2975 Simon Leinen 2976 SWITCH 2977 Werdstrasse 2 2978 P.O. Box 2979 8021 Zurich 2980 Switzerland 2982 Phone: +41 44 268 1536 2983 EMail: simon.leinen@switch.ch 2985 Thomas Dietz 2986 NEC Europe Ltd. 2987 NEC Laboratories Europe 2988 Network Research Division 2989 Kurfuersten-Anlage 36 2990 69115 Heidelberg 2991 Germany 2993 Phone: +49 6221 4342-128 2994 EMail: Thomas.Dietz@nw.neclab.eu