idnits 2.17.1 draft-ietf-ipfix-protocol-rfc5101bis-05.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 (January 7, 2013) is 4128 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: July 11, 2013 January 7, 2013 8 Specification of the IP Flow Information eXport (IPFIX) Protocol 9 for the Exchange of Flow Information 10 draft-ietf-ipfix-protocol-rfc5101bis-05 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 July 11, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . 46 120 10.3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 46 121 10.3.4. Session Establishment and Shutdown . . . . . . . . . 46 122 10.3.5. Failover and Session Duplication . . . . . . . . . . 46 123 10.4. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 124 10.4.1. Congestion Avoidance . . . . . . . . . . . . . . . . 47 125 10.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 47 126 10.4.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 48 127 10.4.4. Connection Establishment, Shutdown, and Restart . . . 48 128 10.4.5. Failover . . . . . . . . . . . . . . . . . . . . . . 49 129 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 130 11.1. Applicability of TLS and DTLS . . . . . . . . . . . . . . 50 131 11.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 51 132 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 51 133 11.4. Protection against DoS Attacks . . . . . . . . . . . . . 52 134 11.5. When DTLS or TLS Is Not an Option . . . . . . . . . . . . 53 135 11.6. Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 53 136 11.7. Securing the Collector . . . . . . . . . . . . . . . . . 54 137 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 138 Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . . 55 139 A.1. Message Header Example . . . . . . . . . . . . . . . . . . 55 140 A.2. Template Set Examples . . . . . . . . . . . . . . . . . . 56 141 A.2.1. Template Set Using IETF-Specified Information 142 Elements . . . . . . . . . . . . . . . . . . . . . . . 56 143 A.2.2. Template Set Using Enterprise-Specific Information 144 Elements . . . . . . . . . . . . . . . . . . . . . . . 56 145 A.3. Data Set Example . . . . . . . . . . . . . . . . . . . . . 58 146 A.4. Options Template Set Examples . . . . . . . . . . . . . . 59 147 A.4.1. Options Template Set Using IETF-Specified 148 Information Elements . . . . . . . . . . . . . . . . . 59 149 A.4.2. Options Template Set Using Enterprise-Specific 150 Information . . . . . . . . . . . . . . . . . . . . . 59 151 A.4.3. Options Template Set Using an Enterprise-Specific 152 Scope . . . . . . . . . . . . . . . . . . . . . . . . 60 153 A.4.4. Data Set Using an Enterprise-Specific Scope . . . . . 61 154 A.5. Variable-Length Information Element Examples . . . . . . . 62 155 A.5.1. Example of Variable-Length Information Element with 156 Length . . . . . . . . . . . . . . . . . . . . . . . . 62 157 A.5.2. Example of Variable-Length Information Element with 158 3 Octet Length Encoding . . . . . . . . . . . . . . . 62 159 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 160 Normative References . . . . . . . . . . . . . . . . . . . . . . . 62 161 Informative References . . . . . . . . . . . . . . . . . . . . . . 64 162 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 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 If present, this Information Element MUST be 1093 defined as a 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 If present, this Information Element MUST be 1125 defined as a 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 any 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 are no 1764 longer being used by the Exporting Process, the Collecting Process 1765 MAY associate a lifetime with each Template received in a UDP 1766 Transport Session. Templates not refreshed by the Exporting Process 1767 within the lifetime can then be discarded by the Collecting Process. 1768 The 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 exporting a new Template for the Template ID after 1778 waiting at least 3 times the retransmission rate. Note that Template 1779 ID reuse may lead to incorrect interpretation of Data Records if the 1780 retransmission and lifetime are not properly configured. 1782 When a Collecting Process receives a new Template Record or Options 1783 Template Record via UDP for an already-allocated Template ID, and 1784 that Template or Options Template is identical to the already- 1785 received Template or Options Template, it SHOULD NOT log the 1786 retransmission, as this is the normal operation of Template refresh 1787 over UDP. 1789 When a Collecting Process receives a new Template Record or Options 1790 Template Record for an already-allocated Template ID, and that 1791 Template or Options Template is different from the already-received 1792 Template or Options Template, the Collecting Process MUST replace the 1793 Template or Options Template for that Template ID with the newly- 1794 received Template or Options Template. This is the normal operation 1795 of Template ID reuse over UDP. 1797 As Template IDs are unique per UDP session and per Observation 1798 Domain, at any given time, the Collecting Process SHOULD maintain the 1799 following for all the current Template Records and Options Template 1800 Records: . 1804 9. The Collecting Process's Side 1806 This section describes the handling of the IPFIX Protocol at the 1807 Collecting Process common to all Transport Protocols. Additional 1808 considerations for SCTP and UDP are given in Sections 9.1 and 9.2 1809 respectively. Template management at Collecting Processes is covered 1810 in Section 8. 1812 The Collecting Process MUST listen for association requests / 1813 connections to start new Transport Sessions from the Exporting 1814 Process. 1816 The Collecting Process MUST note the Information Element identifier 1817 of any Information Element that it does not understand and MAY 1818 discard that Information Element from received Data Records. 1820 The Collecting Process MUST accept padding in Data Records and 1821 Template Records. The padding size is the Set Length minus the size 1822 of the Set Header (4 octets for the Set ID and the Set Length), 1823 modulo the Record size deduced from the Template Record. 1825 The IPFIX protocol has a Sequence Number field in the Export header 1826 that increases with the number of IPFIX Data Records in the IPFIX 1827 Message. The Collecting Process SHOULD detect out-of-sequence, 1828 dropped, or duplicate IPFIX Messages using this the Sequence Number. 1829 If it supports this mechanism, the Collecting Process SHOULD log such 1830 Messages, as these could indicate resource exhaustion at the 1831 Exporting Process or the Collecting Process, an Exporting Process 1832 reset, packet loss due to congestion between the Exporting Process 1833 and the Collecting Process, or message injection. 1835 If the Collecting Process receives a malformed IPFIX Message it MUST 1836 discard the IPFIX Message and SHOULD log the error. A malformed IPFIX 1837 Message is one that cannot be interpreted due to nonsensical length 1838 values (e.g., a variable length Information Element longer than its 1839 enclosing Set, a Set longer than its enclosing Message, a Message 1840 shorter than an IPFIX Message Header) or a reserved Version value 1841 (which may indicate a future version of IPFIX is being used for 1842 export, but practically occurs most often when non-IPFIX data is sent 1843 to an IPFIX Collecting Process, as the Message Header Version field 1844 serves as a de facto magic number for IPFIX). Note that non-zero Set 1845 padding does not constitute a malformed IPFIX Message. 1847 9.1. Additional considerations for SCTP Collecting Processes 1849 The Exporting Process requests a number of streams to use for export 1850 at association setup time. An Exporting Process MAY request and 1851 support more than one stream per SCTP association. 1853 9.2. Additional considerations for UDP Collecting Processes 1855 A Transport Session for IPFIX Messages transported over UDP is 1856 defined from the point of view of the Exporting Process, and roughly 1857 corresponds to the time during which a given Exporting Process sends 1858 IPFIX messages over UDP to a given Collecting Process. Since this is 1859 difficult to detect at the Collecting Process, the Collecting Process 1860 MAY discard all Transport Session state after no IPFIX Messages are 1861 received from a given Exporting Process within a given Transport 1862 Session during a configurable idle timeout. 1864 The Collecting Process SHOULD accept Data Records without the 1865 associated Template Record (or other definitions) required to decode 1866 the Data Record. If the Template Records (or other definitions such 1867 as Common Properties) have not been received at the time Data Records 1868 are received, the Collecting Process MAY store the Data Records for a 1869 short period of time and decode them after the Template Records (or 1870 other definitions) are received, comparing Export Times of IPFIX 1871 Messages containing the Template Records with those containing the 1872 Data Records as in Section 8.2. The short period of time MUST be 1873 lower than the lifetime of definitions associated with identifiers 1874 considered unique within the UDP session. Note that this mechanism 1875 may lead to incorrectly interpreted records in the presence of 1876 Template ID reuse 1878 10. Transport Protocol 1880 The IPFIX Protocol Specification has been designed to be transport 1881 protocol independent. Note that the Exporter can export to multiple 1882 Collecting Processes using independent transport protocols. 1884 The IPFIX Message Header 16-bit Length field limits the length of an 1885 IPFIX Message to 65535 octets, including the header. A Collecting 1886 Process MUST be able to handle IPFIX Message lengths of up to 65535 1887 octets. 1889 10.1. Transport Compliance and Transport Usage 1891 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 1892 MUST be implemented by all compliant implementations. UDP [UDP] MAY 1893 also be implemented by compliant implementations. TCP [TCP] MAY also 1894 be implemented by compliant implementations. 1896 SCTP SHOULD be used in deployments where Exporters and Collectors are 1897 communicating over links that are susceptible to congestion. PR-SCTP 1898 is capable of providing any required degree of reliability. 1900 TCP MAY be used in deployments where Exporters and Collectors 1901 communicate over links that are susceptible to congestion, but SCTP 1902 is preferred due to its ability to limit back pressure on Exporters 1903 and its message versus stream orientation. 1905 UDP MAY be used, although it is not a congestion-aware protocol. 1906 However, in this case the IPFIX traffic between Exporter and 1907 Collector MUST be separately contained or provisioned to minimize the 1908 risk of congestion-related loss. 1910 By default, the Collecting Process listens for connections on SCTP, 1911 TCP, and/or UDP port 4739. By default, the Collecting Process 1912 listens for secure connections on SCTP, TCP, and/or UDP port 4740 1913 (refer to the Security Considerations section). By default, the 1914 Exporting Process attempts to connect to one of these ports. It MUST 1915 be possible to configure both the Exporting and Collecting Processes 1916 to use different SCTP ports that the default. 1918 10.2. SCTP 1920 This section describes how IPFIX is transported over SCTP [RFC4960] 1921 using the PR-SCTP [RFC3758] extension. 1923 10.2.1. Congestion Avoidance 1925 The SCTP transport protocol provides the required level of congestion 1926 avoidance by design. 1928 SCTP detects congestion in the end-to-end path between the IPFIX 1929 Exporting Process and the IPFIX Collecting Process, and limits the 1930 transfer rate accordingly. When an IPFIX Exporting Process has 1931 records to export, but detects that transmission by SCTP is 1932 temporarily impossible, it can either wait until sending is possible 1933 again, or it can decide to drop the record. In the latter case, the 1934 dropped export data SHOULD be accounted for, so that the amount of 1935 dropped export data can be reported using the mechanism in Section 1936 4.3. 1938 10.2.2. Reliability 1940 The SCTP transport protocol is by default reliable, but has the 1941 capability to deliver messages with partial reliability [RFC3758]. 1943 Using reliable SCTP messages for the IPFIX export is not in itself a 1944 guarantee that all Data Records will be delivered. If there is 1945 congestion on the link from the Exporting Process to the Collecting 1946 Process, or if a significant number of retransmissions are required, 1947 the send queues on the Exporting Process may fill up; the Exporting 1948 Process MAY either suspend, export, or discard the IPFIX Messages. 1949 If Data Records are discarded the IPFIX Sequence Numbers used for 1950 export MUST reflect the loss of data. 1952 10.2.3. MTU 1954 SCTP provides the required IPFIX Message fragmentation service based 1955 on path MTU discovery. 1957 10.2.4. Association Establishment and Shutdown 1959 The IPFIX Exporting Process initiates an SCTP association with the 1960 IPFIX Collecting Process. The Exporting Process MAY establish more 1961 than one association (connection "bundle" in SCTP terminology) to the 1962 Collecting Process. 1964 An Exporting Process MAY support more than one active association to 1965 different Collecting Processes (including the case of different 1966 Collecting Processes on the same host). 1968 When an Exporting Process is shut down, it SHOULD shut down the SCTP 1969 association. 1971 When a Collecting Process no longer wants to receive IPFIX Messages, 1972 it SHOULD shut down its end of the association. The Collecting 1973 Process SHOULD continue to receive and process IPFIX Messages until 1974 the Exporting Process has closed its end of the association. 1976 When a Collecting Process detects that the SCTP association has been 1977 abnormally terminated, it MUST continue to listen for a new 1978 association establishment. 1980 When an Exporting Process detects that the SCTP association to the 1981 Collecting Process is abnormally terminated, it SHOULD try to 1982 re-establish the association. 1984 Association timeouts SHOULD be configurable. 1986 10.2.5. Failover 1988 If the Collecting Process does not acknowledge the attempt by the 1989 Exporting Process to establish an association, the Exporting Process 1990 should retry using the SCTP exponential backoff feature. The 1991 Exporter MAY log an alarm if the time to establish the association 1992 exceeds a specified threshold, configurable on the Exporter. 1994 If Collecting Process failover is supported by the Exporting Process, 1995 a second SCTP association MAY be opened in advance. 1997 10.2.6. Streams 1999 An Exporting Process MAY request more than one SCTP stream per 2000 association. Each of these streams may be used for the transmission 2001 of IPFIX Messages containing Data Sets, Template Sets, and/or Options 2002 Template Sets. 2004 Depending on the requirements of the application, the Exporting 2005 Process may send Data Sets with full or partial reliability, using 2006 ordered or out-of-order delivery, over any SCTP stream established 2007 during SCTP Association setup. 2009 An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as 2010 per Section 4 of the PR-SCTP [RFC3758] specification when using 2011 partial reliability to transmit IPFIX Messages containing only Data 2012 Sets. 2014 However, Exporting Processes SHOULD mark such IPFIX Messages for 2015 retransmission for as long as resource or other constraints allow. 2017 10.3. UDP 2019 This section describes how IPFIX is transported over UDP [UDP]. 2021 10.3.1. Congestion Avoidance 2023 UDP has no integral congestion-avoidance mechanism. Its use over 2024 congestion-sensitive network paths is therefore not recommended. UDP 2025 MAY be used in deployments where Exporters and Collectors always 2026 communicate over dedicated links that are not susceptible to 2027 congestion, i.e., links that are over-provisioned compared to the 2028 maximum export rate from the Exporters. 2030 10.3.2. Reliability 2032 UDP is not a reliable transport protocol, and cannot guarantee 2033 delivery of messages. IPFIX Messages sent from the Exporting Process 2034 to the Collecting Process using UDP may therefore be lost. UDP MUST 2035 NOT be used unless the application can tolerate some loss of IPFIX 2036 Messages. 2038 The Collecting Process SHOULD deduce the loss and reordering of IPFIX 2039 Data Records by looking at the discontinuities in the IPFIX Sequence 2040 Number. In the case of UDP, the IPFIX Sequence Number contains the 2041 total number of IPFIX Data Records sent for the UDP Transport Session 2042 prior to the receipt of this IPFIX Message, modulo 2^32. A Collector 2043 SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages 2044 by tracking the Sequence Number. Templates sent from the Exporting 2045 Process to the Collecting Process using UDP as a transport MUST be 2046 re-sent at regular intervals, in case previous copies were lost. 2048 Exporting Processes exporting IPFIX Messages via UDP MUST include a 2049 valid UDP checksum [UDP] in UDP datagrams including IPFIX messages. 2051 10.3.3. MTU 2053 The maximum size of exported messages MUST be configured such that 2054 the total packet size does not exceed the path MTU. If the path MTU 2055 is unknown, a maximum packet size of 512 octets SHOULD be used. 2057 10.3.4. Session Establishment and Shutdown 2059 As UDP is a connectionless protocol, there is no real session 2060 establishment or shutdown for IPFIX over UDP. An Exporting Process 2061 starts sending IPFIX Messages to a Collecting Process at one point in 2062 time, and stops sending them at another point in time. This leads to 2063 some complications in Template management, which are outlined in 2064 Section 8.4 above. 2066 10.3.5. Failover and Session Duplication 2068 Because UDP is not a connection-oriented protocol, the Exporting 2069 Process is unable to determine from the transport protocol that the 2070 Collecting Process is no longer able to receive the IPFIX Messages. 2071 Therefore, it cannot invoke a failover mechanism. However, the 2072 Exporting Process MAY duplicate the IPFIX Message to several 2073 Collecting Processes. 2075 10.4. TCP 2077 The IPFIX Exporting Process initiates a TCP connection to the 2078 Collecting Process. By default, the Collecting Process listens for 2079 connections on TCP port 4739. By default, the Collecting Process 2080 listens for secure connections on TCP port 4740 (refer to the 2081 Security Considerations section). By default, the Exporting Process 2082 tries to connect to one of these ports. It MUST be possible to 2083 configure both the Exporting Process and the Collecting Process to 2084 use a different TCP port. 2086 An Exporting Process MAY support more than one active connection to 2087 different Collecting Processes (including the case of different 2088 Collecting Processes on the same host). 2090 The Exporter MAY log an alarm if the time to establish the connection 2091 exceeds a specified threshold, configurable on the Exporter. 2093 10.4.1. Congestion Avoidance 2095 TCP controls the rate at which data can be sent from the Exporting 2096 Process to the Collecting Process, using a mechanism that takes into 2097 account both congestion in the network and the capabilities of the 2098 receiver. 2100 Therefore, an IPFIX Exporting Process may not be able to send IPFIX 2101 Messages at the rate that the Metering Process generates them, either 2102 because of congestion in the network or because the Collecting 2103 Process cannot handle IPFIX Messages fast enough. As long as 2104 congestion is transient, the Exporting Process can buffer IPFIX 2105 Messages for transmission. But such buffering is necessarily limited, 2106 both because of resource limitations and because of timeliness 2107 requirements, so ongoing and/or severe congestion may lead to a 2108 situation where the Exporting Process is blocked. 2110 When an Exporting Process has Data Records to export but the 2111 transmission buffer is full, and it wants to avoid blocking, it can 2112 decide to drop some Data Records. The dropped Data Records MUST be 2113 accounted for, so that the number of lost records can later be 2114 reported as in Section 4.3. 2116 10.4.2. Reliability 2118 TCP ensures reliable delivery of data from the Exporting Process to 2119 the Collecting Process. 2121 10.4.3. MTU 2123 As TCP offers a stream service instead of a datagram or sequential 2124 packet service, IPFIX Messages transported over TCP are instead 2125 separated using the Length field in the IPFIX Message Header. The 2126 Exporting Process can choose any valid length for exported IPFIX 2127 Messages, as TCP handles segmentation. 2129 However, if an Exporting Process exports data from multiple 2130 Observation Domains, it should be careful to choose IPFIX Message 2131 lengths appropriately to minimize head-of-line blocking between 2132 different Observation Domains. Multiple TCP connections MAY be used 2133 to avoid head-of-line blocking between different Observation Domains. 2135 10.4.4. Connection Establishment, Shutdown, and Restart 2137 The IPFIX Exporting Process initiates a TCP connection to the 2138 Collecting Process. An Exporting Process MAY support more than one 2139 active connection to different Collecting Processes (including the 2140 case of different Collecting Processes on the same host). 2142 The Exporter MAY log an alarm if the time to establish the connection 2143 exceeds a specified threshold, configurable on the Exporter. 2145 When an Exporting Process is shut down, it SHOULD shut down the TCP 2146 connection. 2148 When a Collecting Process no longer wants to receive IPFIX Messages, 2149 it SHOULD close its end of the connection. The Collecting Process 2150 SHOULD continue to read IPFIX Messages until the Exporting Process 2151 has closed its end. 2153 When a Collecting Process detects that the TCP connection to the 2154 Exporting Process has terminated abnormally, it MUST continue to 2155 listen for a new connection. 2157 When an Exporting Process detects that the TCP connection to the 2158 Collecting Process has terminated abnormally, it SHOULD try to 2159 re-establish the connection. Connection timeouts and retry schedules 2160 SHOULD be configurable. In the default configuration, an Exporting 2161 Process MUST NOT attempt to establish a connection more frequently 2162 than once per minute. 2164 10.4.5. Failover 2166 If the Collecting Process does not acknowledge an attempt by the 2167 Exporting Process to establish a connection, TCP will automatically 2168 retry connection establishment using exponential backoff. 2170 If Collecting Process failover is supported by the Exporting Process, 2171 a second TCP connection MAY be opened in advance. 2173 11. Security Considerations 2175 The security considerations for the IPFIX protocol have been derived 2176 from an analysis of potential security threats, as discussed in the 2177 "Security Considerations" section of IPFIX requirements [RFC3917]. 2178 The requirements for IPFIX security are as follows: 2180 1. IPFIX must provide a mechanism to ensure the confidentiality of 2181 IPFIX data transferred from an Exporting Process to a Collecting 2182 Process, in order to prevent disclosure of Flow Records 2183 transported via IPFIX. 2185 2. IPFIX must provide a mechanism to ensure the integrity of IPFIX 2186 data transferred from an Exporting Process to a Collecting 2187 Process, in order to prevent the injection of incorrect data or 2188 control information (e.g., Templates) into an IPFIX Message 2189 stream. 2191 3. IPFIX must provide a mechanism to authenticate IPFIX Collecting 2192 and Exporting Processes, to prevent the collection of data from an 2193 unauthorized Exporting Process or the export of data to an 2194 unauthorized Collecting Process. 2196 Because IPFIX can be used to collect information for network 2197 forensics and billing purposes, attacks designed to confuse, disable, 2198 or take information from an IPFIX collection system may be seen as a 2199 prime objective during a sophisticated network attack. 2201 An attacker in a position to inject false messages into an IPFIX 2202 Message stream can either affect the application using IPFIX (by 2203 falsifying data), or the IPFIX Collecting Process itself (by 2204 modifying or revoking Templates, or changing options); for this 2205 reason, IPFIX Message integrity is important. 2207 The IPFIX Messages themselves may also contain information of value 2208 to an attacker, including information about the configuration of the 2209 network as well as end-user traffic and payload data, so care must be 2210 taken to confine their visibility to authorized users. When an 2211 Information Element containing end-user payload information is 2212 exported, it SHOULD be transmitted to the Collecting Process using a 2213 means that secures its contents against eavesdropping. Suitable 2214 mechanisms include the use of either a direct point-to-point 2215 connection or the use of an encryption mechanism. It is the 2216 responsibility of the Collecting Process to provide a satisfactory 2217 degree of security for this collected data, including, if necessary, 2218 anonymization of any reported data. 2220 11.1. Applicability of TLS and DTLS 2222 Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer 2223 Security (DTLS) [RFC6347] were designed to provide the 2224 confidentiality, integrity, and authentication assurances required by 2225 the IPFIX protocol, without the need for pre-shared keys. 2227 With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC6347] 2228 MUST be implemented. If UDP is selected as the IPFIX transport 2229 protocol, DTLS [RFC6347] MUST be implemented. If TCP is selected as 2230 the IPFIX transport protocol, TLS [RFC5246] MUST be implemented. 2232 Note that DTLS is selected as the security mechanism for SCTP. 2233 Though TLS bindings to SCTP are defined in [RFC3436], they require 2234 all communication to be over reliable, bidirectional streams, and 2235 require one TLS connection per stream. This arrangement is not 2236 compatible with the rationale behind the choice of SCTP as an IPFIX 2237 transport protocol. 2239 Note that using DTLS [RFC6347] has a vulnerability, i.e., a true man 2240 in the middle may attempt to take data out of an association and fool 2241 the sender into thinking that the data was actually received by the 2242 peer. In generic TLS for SCTP (and/or TCP), this is not possible. 2243 This means that the removal of a message may become hidden from the 2244 sender or receiver. Another vulnerability of using SCTP with DTLS is 2245 that someone could inject SCTP control information to shut down the 2246 SCTP association, effectively generating a loss of IPFIX Messages if 2247 those are buffered outside of the SCTP association. Techniques such 2248 as [RFC6083] could be used to overcome these vulnerabilities. 2250 When using DTLS over SCTP, the Exporting Process MUST ensure that 2251 each IPFIX Message is sent over the same SCTP stream that would be 2252 used when sending the same IPFIX Message directly over SCTP. Note 2253 that DTLS may send its own control messages on stream 0 with full 2254 reliability; however, this will not interfere with the processing of 2255 stream 0 IPFIX Messages at the Collecting Process, because DTLS 2256 consumes its own control messages before passing IPFIX Messages up to 2257 the application layer. 2259 When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] 2260 SHOULD be used, especially on long-lived Transport Sessions, to 2261 ensure that the association remains active. 2263 11.2. Usage 2265 The IPFIX Exporting Process initiates the communication to the IPFIX 2266 Collecting Process, and acts as a TLS or DTLS client according to 2267 [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a 2268 TLS or DTLS server. The DTLS client opens a secure connection on the 2269 SCTP port 4740 of the DTLS server if SCTP is selected as the 2270 transport protocol. The TLS client opens a secure connection on the 2271 TCP port 4740 of the TLS server if TCP is selected as the transport 2272 protocol. The DTLS client opens a secure connection on the UDP port 2273 4740 of the DTLS server if UDP is selected as the transport 2274 protocol. 2276 11.3. Authentication 2278 IPFIX Exporting Processes and IPFIX Collecting Processes are 2279 identified by the fully qualified domain name of the interface on 2280 which IPFIX Messages are sent or received, for purposes of X.509 2281 client and server certificates as in [RFC5280]. 2283 To prevent man-in-the-middle attacks from impostor Exporting or 2284 Collecting Processes, the acceptance of data from an unauthorized 2285 Exporting Process, or the export of data to an unauthorized 2286 Collecting Process, strong mutual authentication via asymmetric keys 2287 MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and 2288 Collecting Processes MUST verify the identity of its peer against its 2289 authorized certificates, and MUST verify that the peer's certificate 2290 matches its fully qualified domain name, or, in the case of SCTP, the 2291 fully qualified domain name of one of its endpoints. 2293 The fully qualified domain name used to identify an IPFIX Collecting 2294 Process or Exporting Process may be stored either in a subjectAltName 2295 extension of type dNSName, or in the most specific Common Name field 2296 of the Subject field of the X.509 certificate. If both are present, 2297 the subjectAltName extension is given preference. 2299 Internationalized domain names (IDN) in either the subjectAltName 2300 extension of type dNSName or the most specific Common Name field of 2301 the Subject field of the X.509 certificate MUST be encoded using 2302 Punycode [RFC3492] as described in [RFC5891], "Conversion 2303 Operations". 2305 11.4. Protection against DoS Attacks 2307 An attacker may mount a denial-of-service (DoS) attack against an 2308 IPFIX collection system either directly, by sending large amounts of 2309 traffic to a Collecting Process, or indirectly, by generating large 2310 amounts of traffic to be measured by a Metering Process. 2312 Direct DoS attacks can also involve state exhaustion, whether at the 2313 transport layer (e.g., by creating a large number of pending 2314 connections), or within the IPFIX Collecting Process itself (e.g., by 2315 sending Flow Records pending Template or scope information, a large 2316 amount of Options Template Records, etc.). 2318 SCTP mandates a cookie-exchange mechanism designed to defend against 2319 SCTP state exhaustion DoS attacks. Similarly, TCP provides the "SYN 2320 cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be 2321 used by any Collecting Process accepting TCP connections. DTLS also 2322 provides cookie exchange to protect against DTLS server state 2323 exhaustion. 2325 The reader should note that there is no way to prevent fake IPFIX 2326 Message processing (and state creation) for UDP & SCTP communication. 2327 The use of TLS and DTLS can obviously prevent the creation of fake 2328 states, but they are themselves prone to state exhaustion attacks. 2329 Therefore, Collector rate limiting SHOULD be used to protect TLS & 2330 DTLS (like limiting the number of new TLS or DTLS session per second 2331 to a sensible number). 2333 IPFIX state exhaustion attacks can be mitigated by limiting the rate 2334 at which new connections or associations will be opened by the 2335 Collecting Process, the rate at which IPFIX Messages will be accepted 2336 by the Collecting Process, and adaptively limiting the amount of 2337 state kept, particularly records waiting on Templates. These rate 2338 and state limits MAY be provided by a Collecting Process; if 2339 provided, the limits SHOULD be user configurable. 2341 Additionally, an IPFIX Collecting Process can eliminate the risk of 2342 state exhaustion attacks from untrusted nodes by requiring TLS or 2343 DTLS mutual authentication, causing the Collecting Process to accept 2344 IPFIX Messages only from trusted sources. 2346 With respect to indirect denial of service, the behavior of IPFIX 2347 under overload conditions depends on the transport protocol in use. 2348 For IPFIX over TCP, TCP congestion control would cause the flow of 2349 IPFIX Messages to back off and eventually stall, blinding the IPFIX 2350 system. SCTP improves upon this situation somewhat, as some IPFIX 2351 Messages would continue to be received by the Collecting Process due 2352 to the avoidance of head-of-line blocking by SCTP's multiple streams 2353 and partial reliability features, possibly affording some visibility 2354 of the attack. The situation is similar with UDP, as some datagrams 2355 may continue to be received at the Collecting Process, effectively 2356 applying sampling to the IPFIX Message stream, implying that some 2357 forensics may be left. 2359 To minimize IPFIX Message loss under overload conditions, some 2360 mechanism for service differentiation could be used to prioritize 2361 IPFIX traffic over other traffic on the same link. Alternatively, 2362 IPFIX Messages can be transported over a dedicated network. In this 2363 case, care must be taken to ensure that the dedicated network can 2364 handle the expected peak IPFIX Message traffic. 2366 11.5. When DTLS or TLS Is Not an Option 2368 The use of DTLS or TLS might not be possible in some cases due to 2369 performance issues or other operational concerns. 2371 Without TLS or DTLS mutual authentication, IPFIX Exporting Processes 2372 and Collecting Processes can fall back on using IP source addresses 2373 to authenticate their peers. A policy of allocating Exporting 2374 Process and Collecting Process IP addresses from specified address 2375 ranges, and using ingress filtering to prevent spoofing, can improve 2376 the usefulness of this approach. Again, completely segregating IPFIX 2377 traffic on a dedicated network, where possible, can improve security 2378 even further. In any case, the use of open Collecting Processes 2379 (those that will accept IPFIX Messages from any Exporting Process 2380 regardless of IP address or identity) is discouraged. 2382 Modern TCP and SCTP implementations are resistant to blind insertion 2383 attacks (see [RFC4960], [RFC6528]); however, UDP offers no such 2384 protection. For this reason, IPFIX Message traffic transported via 2385 UDP and not secured via DTLS SHOULD be protected via segregation to a 2386 dedicated network. 2388 11.6. Logging an IPFIX Attack 2390 IPFIX Collecting Processes MUST detect potential IPFIX Message 2391 insertion or loss conditions by tracking the IPFIX Sequence Number, 2392 and SHOULD provide a logging mechanism for reporting out-of-sequence 2393 messages. Note that an attacker may be able to exploit the handling 2394 of out-of-sequence messages at the Collecting Process, so care should 2395 be taken in handling these conditions. For example, a Collecting 2396 Process that simply resets the expected Sequence Number upon receipt 2397 of a later Sequence Number could be temporarily blinded by deliberate 2398 injection of later Sequence Numbers. 2400 IPFIX Exporting and Collecting Processes SHOULD log any connection 2401 attempt that fails due to authentication failure, whether due to 2402 being presented an unauthorized or mismatched certificate during TLS 2403 or DTLS mutual authentication, or due to a connection attempt from an 2404 unauthorized IP address when TLS or DTLS is not in use. 2406 IPFIX Exporting and Collecting Processes SHOULD detect and log any 2407 SCTP association reset or TCP connection reset. 2409 11.7. Securing the Collector 2411 The security of the Collector and its implementation is important to 2412 achieve overall security. However, it is outside the scope of this 2413 document. 2415 12. IANA Considerations 2417 IPFIX Messages use two fields with assigned values. These are the 2418 IPFIX Version Number, indicating which version of the IPFIX Protocol 2419 was used to export an IPFIX Message, and the IPFIX Set ID, indicating 2420 the type for each set of information within an IPFIX Message. 2422 The Information Elements used by IPFIX, and sub-registries of 2423 Information Element values, are managed by IANA [IPFIX-IANA], as are 2424 the Private Enterprise Numbers used by enterprise-specific 2425 Information Elements [PEN-IANA]. This document makes no changes to 2426 these registries. 2428 The IPFIX Version Number value of 0x000a (10) is reserved for the 2429 IPFIX protocol specified in this document. Set ID values of 0 and 1 2430 are not used, for historical reasons [RFC3954]. The Set ID value of 2431 2 is reserved for the Template Set. The Set ID value of 3 is 2432 reserved for the Options Template Set. All other Set ID values from 2433 4 to 255 are reserved for future use. Set ID values above 255 are 2434 used for Data Sets. 2436 New assignments in either IPFIX Version Number or IPFIX Set ID 2437 assignments require a Standards Action [RFC5226], i.e., they are to 2438 be made via Standards Track RFCs approved by the IESG. 2440 [NOTE for IANA: Please change references in the IPFIX Information 2441 Element Registry to RFC5101 to point to this document, instead.] 2443 Appendix A. IPFIX Encoding Examples 2445 This appendix, which is a not a normative reference, contains IPFIX 2446 encoding examples. 2448 Let's consider the example of an IPFIX Message composed of a 2449 Template Set, a Data Set (which contains three Data Records), an 2450 Options Template Set and a Data Set (which contains 2 Data Records 2451 related to the previous Options Template Record). 2453 IPFIX Message: 2455 +--------+------------------------------------------. . . 2456 | | +--------------+ +------------------+ 2457 |Message | | Template | | Data | 2458 | Header | | Set | | Set | . . . 2459 | | | (1 Template) | | (3 Data Records) | 2460 | | +--------------+ +------------------+ 2461 +--------+------------------------------------------. . . 2463 . . .-------------------------------------------+ 2464 +------------------+ +------------------+ | 2465 | Options | | Data | | 2466 . . . | Template Set | | Set | | 2467 | (1 Template) | | (2 Data Records) | | 2468 +------------------+ +------------------+ | 2469 . . .-------------------------------------------+ 2471 A.1. Message Header Example 2473 The Message Header is composed of: 2474 0 1 2 3 2475 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 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | Version = 0x000a | Length = 152 | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | Export Time | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Sequence Number | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | Observation Domain ID | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 A.2. Template Set Examples 2488 A.2.1. Template Set Using IETF-Specified Information Elements 2490 We want to report the following Information Elements: 2492 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], 2493 with a length of 4 octets 2495 - The IPv4 destination IP address: destinationIPv4Address in 2496 [IPFIX-IANA], with a length of 4 octets 2498 - The next-hop IP address (IPv4): ipNextHopIPv4Address in 2499 [IPFIX-IANA], with a length of 4 octets 2501 - The number of packets of the Flow: packetDeltaCount in 2502 [IPFIX-IANA], with a length of 4 octets 2504 - The number of octets of the Flow: octetDeltaCount in 2505 [IPFIX-IANA], with a length of 4 octets 2507 Therefore, the Template Set will be composed of the following: 2509 0 1 2 3 2510 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 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | Set ID = 2 | Length = 28 octets | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | Template ID 256 | Field Count = 5 | 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 |0| sourceIPv4Address = 8 | Field Length = 4 | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 |0| destinationIPv4Address = 12 | Field Length = 4 | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 |0| ipNextHopIPv4Address = 15 | Field Length = 4 | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 |0| packetDeltaCount = 2 | Field Length = 4 | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 |0| octetDeltaCount = 1 | Field Length = 4 | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 A.2.2. Template Set Using Enterprise-Specific Information Elements 2529 We want to report the following Information Elements: 2531 - The IPv4 source IP address: sourceIPv4Address in [IPFIX-IANA], with 2532 a length of 4 octets 2534 - The IPv4 destination IP address: destinationIPv4Address in [IPFIX- 2535 IANA], with a length of 4 octets 2537 - An enterprise-specific Information Element representing 2538 proprietary information, with a type of 15 and a length of 4 2540 - The number of packets of the Flow: packetDeltaCount in [IPFIX- 2541 IANA], with a length of 4 octets 2543 - The number of octets of the Flow: octetDeltaCount in [IPFIX-IANA], 2544 with a length of 4 octets 2546 Therefore, the Template Set will be composed of the following: 2548 0 1 2 3 2549 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 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Set ID = 2 | Length = 32 octets | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Template ID 257 | Field Count = 5 | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 |0| sourceIPv4Address = 8 | Field Length = 4 | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 |0| destinationIPv4Address = 12 | Field Length = 4 | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 |1| Information Element Id. = 15| Field Length = 4 | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | Enterprise number | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 |0| packetDeltaCount = 2 | Field Length = 4 | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 |0| octetDeltaCount = 1 | Field Length = 4 | 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 A.3. Data Set Example 2570 In this example, we report the following three Flow Records: 2572 Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets 2573 | | | Number | Number 2574 ------------------------------------------------------------------ 2575 192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385 2576 192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934 2577 192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534 2579 0 1 2 3 2580 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 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | Set ID = 256 | Length = 64 | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | 192.0.2.12 | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | 192.0.2.254 | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | 192.0.2.1 | 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | 5009 | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | 5344385 | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | 192.0.2.27 | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | 192.0.2.23 | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | 192.0.2.2 | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | 748 | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 | 388934 | 2603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2604 | 192.0.2.56 | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | 192.0.2.65 | 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | 192.0.2.3 | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | 5 | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | 6534 | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Note that padding is not necessary in this example. 2617 A.4. Options Template Set Examples 2619 A.4.1. Options Template Set Using IETF-Specified Information Elements 2621 Per line card (the router being composed of two line cards), we want 2622 to report the following Information Elements: 2624 - Total number of IPFIX Messages: exportedMessageTotalCount [IPFIX- 2625 IANA], with a length of 2 octets 2627 - Total number of exported Flows: exportedFlowRecordTotalCount 2628 [IPFIX-IANA], with a length of 2 octets 2630 The line card, which is represented by the lineCardId Information 2631 Element [IPFIX-IANA], is used as the Scope Field. 2633 Therefore, the Options Template Set will be: 2635 0 1 2 3 2636 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 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | Set ID = 3 | Length = 24 | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | Template ID 258 | Field Count = 3 | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | Scope Field Count = 1 |0| lineCardId = 141 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | Scope 1 Field Length = 4 |0|exportedMessageTotalCount=41 | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | Field Length = 2 | Padding | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 A.4.2. Options Template Set Using Enterprise-Specific Information 2652 Elements 2654 Per line card (the router being composed of two line cards), we want 2655 to report the following Information Elements: 2657 - Total number of IPFIX Messages: exportedMessageTotalCount 2658 [IPFIX-IANA], with a length of 2 octets 2660 - An enterprise-specific number of exported Flows, with a type of 2661 42 and a length of 4 octets 2663 The line card, which is represented by the lineCardId Information 2664 Element [IPFIX-IANA], is used as the Scope Field. 2666 The format of the Options Template Set is as follows: 2668 0 1 2 3 2669 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 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | Set ID = 3 | Length = 28 | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | Template ID 259 | Field Count = 3 | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | Scope Field Count = 1 |0| lineCardId = 141 | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | Scope 1 Field Length = 4 |0|exportedFlowRecordTotalCo.=41| 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | Field Length = 2 |1|Information Element Id. = 42 | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | Field Length = 4 | Enterprise number ... 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 ... Enterprise number | Padding | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 A.4.3. Options Template Set Using an Enterprise-Specific Scope 2688 In this example, we want to export the same information as in the 2689 example in Section A.4.1: 2691 - Total number of IPFIX Messages: exportedMessageTotalCount 2692 [IPFIX-IANA], with a length of 2 octets 2694 - Total number of exported Flows: exportedFlowRecordTotalCount 2695 [IPFIX-IANA], with a length of 2 octets 2697 But this time, the information pertains to a proprietary scope, 2698 identified by enterprise-specific Information Element number 123. 2700 The format of the Options Template Set is now as follows: 2702 0 1 2 3 2703 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 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | Set ID = 3 | Length = 28 | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | Template ID 260 | Field Count = 3 | 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2711 | Scope 1 Field Length = 4 | Enterprise Number ... 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 ... Enterprise Number |0|exportedMessageTotalCount=41 | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | Field Length = 2 |0|exportedFlowRecordTotalCo.=42| 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | Field Length = 2 | Padding | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 A.4.4. Data Set Using an Enterprise-Specific Scope 2722 In this example, we report the following two Data Records: 2724 Enterprise field 123 | IPFIX Message | Exported Flow Records 2725 ------------------------------------------------------------------- 2726 1 | 345 | 10201 2727 2 | 690 | 20402 2729 0 1 2 3 2730 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 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Set ID = 260 | Length = 20 | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | 1 | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | 345 | 10201 | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | 2 | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | 690 | 20402 | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2743 A.5. Variable-Length Information Element Examples 2745 A.5.1. Example of Variable-Length Information Element with Length 2746 Inferior to 255 Octets 2748 0 1 2 3 2749 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 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 | 5 | 5 octet Information Element | 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 A.5.2. Example of Variable-Length Information Element with 3 Octet 2757 Length Encoding 2759 0 1 2 3 2760 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 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | 255 | 1000 | IE ... | 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | 1000 octet Information Element | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 : ... : 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | ... IE | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 References 2773 Normative References 2775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2776 Requirement Levels", BCP 14, RFC 2119, March 1997. 2778 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2779 Layer Security over Stream Control Transmission 2780 Protocol", RFC 3436, December 2002. 2782 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of 2783 Unicode for Internationalized Domain Names in 2784 Applications (IDNA)", RFC 3492, March 2003. 2786 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2787 10646", RFC 3629, November 2003. 2789 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2790 Conrad, "Stream Control Transmission Protocol (SCTP) 2791 Partial Reliability Extension", RFC 3758, May 2004. 2793 [RFC4960] Stewart, R., Ed., "Stream Control Transmission 2794 Protocol", RFC 4960, September 2007. 2796 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2797 an IANA Considerations Section in RFCs", BCP 26, RFC 2798 5226, May 2008. 2800 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2801 Security (TLS) Protocol Version 1.2", RFC 5246, August 2802 2008. 2804 [RFC5280] Cooper, D., Santesson, S., Farrell, S. Boeyen, S. 2805 Housley, R., and W. Polk, "Internet X.509 Public Key 2806 Infrastructure Certificate and Certificate Revocation 2807 List (CRL) Profile", RFC 5280, April 2008. 2809 [RFC5905] Mills, D., Delaware, U., Martin, J., Burbank, J. and 2810 W. Kasch, "Network Time Protocol Version 4: Protocol 2811 and Algorithms Specification", RFC 5905, June 2010 2813 [RFC5891] J. Klensin, "Internationalized Domain Names in 2814 Applications (IDNA): Protocol", RFC 5891, August 2010. 2816 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport 2817 Layer Security Version 1.2", RFC 6347, January 2012. 2819 [RFC6520] Seggelmann, R., Tuexen, M., and Williams, M., 2820 "Transport Layer Security (TLS) and Datagram Transport 2821 Layer Security (DTLS) Heartbeat Extension", RFC 6520, 2822 February 2012. 2824 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 2825 RFC 793, September 1981. 2827 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2828 August 1980. 2830 [RFC5102bis] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. 2831 Meyer, "Information Model for IP Flow Information 2832 Export", draft-claise-ipfix-information-model- 2833 rfc5102bis-01.txt, Work in Progress, October 2011. 2835 [IPFIX-IANA] http://www.iana.org/assignments/ipfix/ipfix.xml 2837 Informative References 2839 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2840 "Textual Conventions for SMIv2", STD 58, RFC 2579, 2841 April 1999. 2843 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2844 Jacobson, "RTP: A Transport Protocol for Real-Time 2845 Applications", STD 64, RFC 3550, July 2003. 2847 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2848 "Requirements for IP Flow Information Export (IPFIX)", 2849 RFC 3917, October 2004. 2851 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 2852 Export Version 9", RFC 3954, October 2004. 2854 [RFC5101] Claise, B., Ed., "Bidirectional Flow Export Using IP 2855 Flow Information Export (IPFIX)", RFC 5103, January 2856 2008. 2858 [RFC5103] Trammell, B., and E. Boschi, "Specification of the IP 2859 Flow Information Export (IPFIX) Protocol for the 2860 Exchange of IP Traffic Flow Information", RFC 5101, 2861 January 2008. 2863 [RFC5153] Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP 2864 Flow Information Export (IPFIX) Implementation 2865 Guidelines", RFC5153, April 2008 2867 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 2868 Quittek, "Architecture for IP Flow Information 2869 Export", RFC5470, March 2009. 2871 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 2872 "IP Flow Information Export (IPFIX) Applicability", 2873 RFC5472, March 2009. 2875 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 2876 for IP Flow Information Export (IPFIX) Testing", 2877 RFC5471, March 2009 2879 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2880 Redundancy in IP Flow Information Export (IPFIX) and 2881 Packet Sampling (PSAMP) Reports", RFC5473, March 2009 2883 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2884 "Exporting Type Information for IP Flow Information 2885 Export (IPFIX) Information Elements", RFC 5610, July 2886 2009. 2888 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2889 Wagner, "Specification of the IP Flow Information 2890 Export (IPFIX) File Format", RFC 5655, October 2009. 2892 [RFC6083] Tuexen, M., Seggelman, R. and E. Rescola, "Datagram 2893 Transport Layer Security (DTLS) for Stream Control 2894 Transmission Protocol (SCTP)", RFC6083, January 2011. 2896 [RFC6313] Claise, B., Dhandapani, G., Aitken, P, and S. Yates, 2897 "Export of Structured Data in IP Flow Information 2898 Export (IPFIX)", RFC6313, July 2011. 2900 [RFC6183] Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, 2901 "IP Flow Information Export (IPFIX) Mediation: 2902 Framework", RFC6183, April 2011. 2904 [RFC6526] Claise, B., Aitken, P., Johnson, A. and G. Muenz, 2905 "IPFIX Export per SCTP Stream", RFC 6526, March 2012. 2907 [RFC6528] Gont, F. and S. Bellovin, "Defending Against Sequence 2908 Number Attacks", RFC 6528, February 2012. 2910 [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 2911 "Definitions of Managed Objects for IP Flow 2912 Information Export", RFC 6615, June 2012. 2914 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration 2915 Data Model for IPFIX and PSAMP", RFC 6728, October 2916 2012. 2918 [PEN-IANA] IANA Private Enterprise Numbers registry 2919 http://www.iana.org/assignments/enterprise-numbers. 2921 [POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information 2922 Technology - Portable Operating System Interface, 2923 IEEE, 2008. 2925 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 2926 "Standard for Binary Floating-Point Arithmetic", IEEE 2927 Standard 754, August 1985. 2929 [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, 2930 "Specification of the Protocol for IPFIX Mediations", 2931 draft-ietf-ipfix-mediation-protocol-02, Work in 2932 Progress, July 2012. 2934 Acknowledgments 2936 We would like to thank the following persons: Ganesh Sadasivan for 2937 his significant contribution during the initial phases of the 2938 protocol specification; Juergen Quittek for the coordination job 2939 within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and 2940 Andrew Johnson for the thorough reviews; Randall Stewart and Peter 2941 Lei for their SCTP expertise and contributions; Martin Djernaes for 2942 the first essay on the SCTP section; Michael Behringer and Eric 2943 Vyncke for their advice and knowledge in security; Michael Tuexen for 2944 his help regarding the DTLS section; Elisa Boschi for her 2945 contribution regarding the improvement of SCTP sections; Mark 2946 Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter 2947 Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul 2948 Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical 2949 reviews and feedback. 2951 Authors' Addresses 2953 Benoit Claise (Ed.) 2954 Cisco Systems 2955 De Kleetlaan 6a b1 2956 1831 Diegem 2957 Belgium 2959 Phone: +32 2 704 5622 2960 EMail: bclaise@cisco.com 2962 Brian Trammell (Ed.) 2963 Swiss Federal Institute of Technology Zurich 2964 Gloriastrasse 35 2965 8092 Zurich 2966 Switzerland 2968 Phone: +41 44 632 70 13 2969 EMail: trammell@tik.ee.ethz.ch 2970 Stewart Bryant 2971 Cisco Systems, Inc. 2972 250, Longwater, 2973 Green Park, 2974 Reading, RG2 6GB, 2975 United Kingdom 2977 Phone: +44 (0)20 8824-8828 2978 EMail: stbryant@cisco.com 2980 Simon Leinen 2981 SWITCH 2982 Werdstrasse 2 2983 P.O. Box 2984 8021 Zurich 2985 Switzerland 2987 Phone: +41 44 268 1536 2988 EMail: simon.leinen@switch.ch 2990 Thomas Dietz 2991 NEC Europe Ltd. 2992 NEC Laboratories Europe 2993 Network Research Division 2994 Kurfuersten-Anlage 36 2995 69115 Heidelberg 2996 Germany 2998 Phone: +49 6221 4342-128 2999 EMail: Thomas.Dietz@nw.neclab.eu