idnits 2.17.1 draft-ietf-ipfix-mediation-protocol-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 6, 2012) is 4310 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) == Unused Reference: 'RFC2119' is defined on line 1101, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-protocol-rfc5101bis-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipfix-protocol-rfc5101bis' == Outdated reference: A later version (-10) exists of draft-ietf-ipfix-information-model-rfc5102bis-02 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-18) exists of draft-ietf-ipfix-flow-selection-tech-11 == Outdated reference: A later version (-08) exists of draft-ietf-ipfix-a9n-05 == Outdated reference: A later version (-06) exists of draft-ietf-ipfix-psamp-mib-05 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Claise 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Kobayashi 5 Expires: January 7, 2013 NTT 6 B. Trammell 7 ETH Zurich 8 July 6, 2012 10 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX 11 Mediators 12 draft-ietf-ipfix-mediation-protocol-02.txt 14 Abstract 16 This document specifies the the operation of the IP Flow Information 17 Export (IPFIX) protocol specific to IPFIX Mediators, including 18 Template and Observation Point management, timing considerations, and 19 other Mediator-specific concerns. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 57 1.2. IPFIX Mediator Documents Overview . . . . . . . . . . . . 4 58 1.3. Relationship with IPFIX and PSAMP . . . . . . . . . . . . 5 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Handling IPFIX Message Headers . . . . . . . . . . . . . . . . 8 61 4. Template Management . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Passing Unmodified Templates through a Mediator . . . . . 10 63 4.2. Creating New Templates at a Mediator . . . . . . . . . . . 14 64 4.3. Information Element Ordering within Templates . . . . . . 15 65 4.4. Handling Unknown Information Elements . . . . . . . . . . 15 66 5. Preserving Original Observation Point Information . . . . . . 15 67 5.1. originalExporterIPv4Address Information Element . . . . . 17 68 5.2. originalExporterIPv6Address Information Element . . . . . 17 69 6. Managing Observation Domain IDs . . . . . . . . . . . . . . . 18 70 6.1. originalObservationDomainId Information Element . . . . . 18 71 7. Timing Considerations . . . . . . . . . . . . . . . . . . . . 19 72 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 20 73 9. Collecting Process Considerations . . . . . . . . . . . . . . 20 74 10. Specific Reporting Requirements . . . . . . . . . . . . . . . 21 75 10.1. Intermediate Process Reliability Statistics Template . . . 21 76 10.2. Flow Key Options Template . . . . . . . . . . . . . . . . 22 77 10.3. intermediateProcessId Information Element . . . . . . . . 23 78 10.4. ignoredRecordTotalCount Information Element . . . . . . . 23 79 11. Configuration Management . . . . . . . . . . . . . . . . . . . 23 80 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 85 15.2. Informative References . . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 The IPFIX architectural components in [RFC5470] consist of IPFIX 91 Devices and IPFIX Collectors communicating using the IPFIX protocol 92 [I-D.ietf-ipfix-protocol-rfc5101bis], which specifies how to export 93 IP Flow information. This protocol is designed to export information 94 about IP traffic Flows and related measurement data, where a Flow is 95 defined by a set of key attributes (e.g. source and destination IP 96 address, source and destination port, etc.). 98 However, thanks to its Template mechanism, the IPFIX protocol can 99 export any type of information, as long as the relevant Information 100 Element is specified in the IPFIX Information Model 101 [I-D.ietf-ipfix-information-model-rfc5102bis], registered with IANA, 102 or specified as an enterprise-specific Information Element. The 103 specifications in the IPFIX protocol 104 [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the 105 context of an IPFIX Mediator receiving, aggregating, correlating, 106 anonymizing, etc... Flow Records from the one or multiple Exporters. 107 Indeed, the IPFIX protocol must be adapted for Intermediate 108 Processes, as defined in the IPFIX Mediation Reference Model as 109 specified in Figure A of [RFC6183], which is based on the IPFIX 110 Mediation Problem Statement [RFC5982]. 112 This document specifies the IP Flow Information Export (IPFIX) 113 protocol in the context of the implementation and deployment of IPFIX 114 Mediators. The use of the IPFIX protocol within a Mediator -- a 115 device which contains both as a Collecting Process and an Exporting 116 Process -- has an impact on the technical details of the usage of the 117 protocol. An overview of the technical problem is covered in section 118 6 of [RFC5982]: loss of original exporter information, loss of base 119 time information, transport sessions management, loss of Options 120 Template Information, Template Id management, considerations for 121 network considerations for aggregation. 123 The specifications in this document are based on the IPFIX protocol 124 specifications [I-D.ietf-ipfix-protocol-rfc5101bis] but adapted 125 according to the IPFIX Mediation Framework [RFC6183]. 127 1.1. IPFIX Documents Overview 129 The IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] provides 130 network administrators with access to IP Flow information. 132 The architecture for the export of measured IP Flow information out 133 of an IPFIX Exporting Process to a Collecting Process is defined in 134 the IPFIX Architecture [RFC5470], per the requirements defined in the 135 IPFIX Requirement doc, [RFC3917]. 137 The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and 138 Templates are carried via a congestion-aware transport protocol from 139 IPFIX Exporting Processes to IPFIX Collecting Processes. 141 IPFIX has a formal description of IPFIX Information Elements, their 142 name, type and additional semantic information, as specified in the 143 IPFIX Information Model 144 [I-D.ietf-ipfix-information-model-rfc5102bis]. 146 The IPFIX Applicability Statement [RFC5472] describes what type of 147 applications can use the IPFIX protocol and how they can use the 148 information provided. It furthermore shows how the IPFIX framework 149 relates to other architectures and frameworks. 151 "IPFIX Mediation: Problem Statement" [RFC5982], describing the IPFIX 152 Mediation applicability examples, along with some problems that 153 network administrators have been facing, is the basis for the "IPFIX 154 Mediation: Framework" [RFC6183]. This framework details the IPFIX 155 Mediation reference model and the components of an IPFIX Mediator. 157 1.2. IPFIX Mediator Documents Overview 159 The "IPFIX Mediation: Problem Statement" [RFC5982] provides an 160 overview of the applicability of Mediators, and defines requirements 161 for Mediators in general terms. This document is of use largely to 162 define the problems to be solved through the deployment of IPFIX 163 Mediators, and to provide scope to the role of Mediators within an 164 IPFIX collection infrastructure. 166 The "IPFIX Mediation: Framework" [RFC6183] provides more 167 architectural details of the arrangement of Intermediate Processes 168 within a Mediator. 170 The details of specific Intermediate Processes, when these have 171 additional export specifications (e.g., metadata about the 172 intermediate processing conveyed through IPFIX Options Templates), 173 are each treated in their own document (e.g., the "IP Flow 174 Anonymization Support" [RFC6235]). Documents specifying the 175 operations of specific Intermediate Processes cover the operation of 176 these Processes within the Mediator framework, and comply with the 177 specifications given in this document; they may additionally specify 178 the operation of the process independently, outside the context of a 179 Mediator, when this is appropriate. As of today, these documents 180 are: 182 1. "IP Flow Anonymization Support", [RFC6235], which describes 183 Anonymization techniques for IP flow data and the export of 184 Anonymized data using the IPFIX protocol. 186 2. "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech], 187 which describes the process of selecting a subset of flows from 188 all flows observed at an observation point, the flow selection 189 motivations, and some specific flow selection techniques. 191 3. "Exporting Aggregated Flow Data using IP Flow Information Export" 192 [I-D.ietf-ipfix-a9n] which describes Aggregated Flow export 193 within the framework of IPFIX Mediators and defines an 194 interoperable, implementation-independent method for Aggregated 195 Flow export. 197 This document specifies the IP Flow Information Export (IPFIX) 198 protocol specific to Mediation, i.e. the specifications that all 199 Intermediate Processes type must comply to. Some extra 200 specifications might be required per Intermediate Process type (In 201 which case, the Intermediate Process specific document would cover 202 those). 204 1.3. Relationship with IPFIX and PSAMP 206 The specification in this document applies to the IPFIX protocol 207 specifications [I-D.ietf-ipfix-protocol-rfc5101bis]. All 208 specifications from [I-D.ietf-ipfix-protocol-rfc5101bis] apply unless 209 specified otherwise in this document. 211 As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are 212 based on the IPFIX protocol specifications, the specifications in 213 this document are also valid for the PSAMP protocol. Therefore, the 214 method specified by this document also applies to PSAMP. 216 2. Terminology 218 [EDITOR'S NOTE: change to only define terms in this section that are 219 actually used in the document.] 221 [EDITOR'S NOTE: Definition change proposal for the Intermediate 222 Process, Intermediate Conversion Process, Intermediate Selection 223 Process, Intermediate Anonymization Process, and IPFIX Mediator. See 224 http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html. 225 However, the definitions are copied over verbatim from RFC6183. Also 226 note that Intermediate Anonymization Process in this document is not 227 in line with the RFC6235.] 229 IPFIX-specific terms, such as Observation Domain, Flow, Flow Key, 230 Metering Process, Exporting Process, Exporter, IPFIX Device, 231 Collecting Process, Collector, Template, IPFIX Message, Message 232 Header, Template Record, Data Record, Options Template Record, Set, 233 Data Set, Information Element, and Transport Session, used in this 234 document are defined in [I-D.ietf-ipfix-protocol-rfc5101bis]. The 235 PSAMP-specific terms used in this document, such as Filtering and 236 Sampling, are defined in [RFC5476]. 238 IPFIX Mediation terms related to aggregation, such as the Interval, 239 Aggregated Flow, and Aggregated Function are defined in 240 [I-D.ietf-ipfix-a9n]. 242 The IPFIX Mediation-specific terminology used in this document is 243 defined in "IPFIX Mediation: Problem Statement" [RFC5982], and reused 244 in "IPFIX Mediation: Framework" [RFC6183]. However, since both of 245 those documents are an informational RFCs, the definitions have been 246 reproduced here along with additional definitions. 248 Similarly, since [RFC6235] is an experimental RFC, the Anonymization 249 Record, Anonymized Data Record, and Intermediate Anonymization 250 Process terms, specified in [RFC6235], are also reproduced here. 252 In this document, as in [I-D.ietf-ipfix-protocol-rfc5101bis], 253 [RFC5476], [I-D.ietf-ipfix-a9n], and [RFC6235], the first letter of 254 each IPFIX-specific and PSAMP-specific term is capitalized along with 255 the IPFIX Mediation-specific term defined here. In this document, we 256 call a stream of records carrying flow- or packet-based information a 257 "record stream". The records may be encoded as IPFIX Data Records of 258 any other format. 260 Transport Session Information: The Transport Session is specified 261 in [I-D.ietf-ipfix-protocol-rfc5101bis]. In SCTP, the Transport 262 Session Information is the SCTP association. In TCP and UDP, the 263 Transport Session Information corresponds to a 5-tuple {Exporter 264 IP address, Collector IP address, Exporter transport port, 265 Collector transport port, transport protocol}. 267 Original Exporter: An Original Exporter is an IPFIX Device that 268 hosts the Observation Points where the metered IP packets are 269 observed. 271 Original Observation Point: An Observation Point of the Original 272 Exporter. In the case of the Intermediate Aggregation Process on 273 an IPFIX Mediator, the Original Observation Point can be composed 274 of, but not limited to, a (set of) specific exporter(s), a (set 275 of) specific interface(s) on an Exporter, a (set of) line card(s) 276 on an Exporter, or any combinations of these. 278 IPFIX Mediation: IPFIX Mediation is the manipulation and conversion 279 of a record stream for subsequent export using the IPFIX protocol. 281 Template Mapping: A mapping from Template Records and/or Options 282 Template Records received by a Mediator to Template Records and/or 283 Options Template Records sent by that IPFIX Mediator. Each entry 284 in a Template Mapping is scoped by incoming or outgoing Transport 285 Session and Observation Domain, as with Templates and Options 286 Templates in the IPFIX Protocol. 288 Anonymization Record: A record that defines the properties of the 289 anonymization applied to a single Information Element within a 290 single Template or Options Template, as in [RFC6235]. 292 Anonymized Data Record: A Data Record within a Data Set containing 293 at least one Information Element with Anonymized values. The 294 Information Element(s) within the Template or Options Template 295 describing this Data Record SHOULD have a corresponding 296 Anonymization Record, as in [RFC6235]. 298 The following terms are used in this document to describe the 299 architectural entities used by IPFIX Mediation. 301 Intermediate Process: An Intermediate Process takes a record stream 302 as its input from Collecting Processes, Metering Processes, IPFIX 303 File Readers, other Intermediate Processes, or other record 304 sources; performs some transformations on this stream, based upon 305 the content of each record, states maintained across multiple 306 records, or other data sources; and passes the transformed record 307 stream as its output to Exporting Processes, IPFIX File Writers, 308 or other Intermediate Processes, in order to perform IPFIX 309 Mediation. Typically, an Intermediate Process is hosted by an 310 IPFIX Mediator. Alternatively, an Intermediate Process may be 311 hosted by an Original Exporter. 313 IPFIX Mediator: An IPFIX Mediator is an IPFIX Device that provides 314 IPFIX Mediation by receiving a record stream from some data 315 sources, hosting one or more Intermediate Processes to transform 316 that stream, and exporting the transformed record stream into 317 IPFIX Messages via an Exporting Process. In the common case, an 318 IPFIX Mediator receives a record stream from a Collecting Process, 319 but it could also receive a record stream from data sources not 320 encoded using IPFIX, e.g., in the case of conversion from the 321 NetFlow V9 protocol [RFC3954] to IPFIX protocol. 323 Specific Intermediate Processes are described below. However, this 324 is not an exhaustive list. 326 Intermediate Conversion Process: An Intermediate Conversion Process 327 is an Intermediate Process that transforms non-IPFIX into IPFIX, 328 or manages the relation among Templates and states of incoming/ 329 outgoing Transport Sessions (or equivalent for non IPFIX 330 protocols) in the case of transport protocol conversion (e.g., 331 from UDP to SCTP). 333 Intermediate Aggregation Process: An Intermediate Aggregation 334 Process is an Intermediate Process that aggregates records based 335 upon a set of Flow Keys or functions applied to fields from the 336 record (e.g., binning and subnet aggregation). 338 Intermediate Correlation Process: An Intermediate Correlation 339 Process is an Intermediate Process that adds information to 340 records, noting correlations among them, or generates new records 341 with correlated data from multiple records (e.g., the production 342 of bidirectional flow records from unidirectional flow records). 344 Intermediate Selection Process: An Intermediate Selection Process 345 is an Intermediate Process that selects records from a sequence 346 based upon criteria-evaluated record values and passes only those 347 records that match the criteria (e.g., Filtering only records from 348 a given network to a given Collector). 350 Intermediate Anonymization Process: An Intermediate Anonymization 351 Process is an Intermediate Process that transforms records in 352 order to anonymize them, to protect the identity of the entities 353 described by the records (e.g., by applying prefix-preserving 354 pseudonymization of IP addresses). 356 3. Handling IPFIX Message Headers 358 The format of the IPFIX Message Header as exported by an IPFIX 359 Mediator is shown in Figure 1. Note that the format is compatible 360 with the IPFIX Message Header defined in 361 [I-D.ietf-ipfix-protocol-rfc5101bis], with some field definitions 362 (for the example, the Export Time) updated in the context of the 363 IPFIX Mediator. 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Version | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Export Time | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Sequence Number | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Observation Domain ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 1: IP Message Header format 379 The header fields as exported by an IPFIX Mediator are describe 380 below. 382 Version: Version of Flow Record format exported in this message. 383 The value of this field is 0x000a for the current version, 384 incrementing by one the version used in the NetFlow services 385 export version 9 [RFC3954]. 387 Length: Total length of the IPFIX Message, measured in octets, 388 including Message Header and Set(s). 390 Export Time: Time at which the IPFIX Message leaves the Mediator, 391 expressed in seconds since the UNIX epoch of 1 January 1970 at 392 00:00 UTC, as defined in [POSIX.1] encoded as an unsigned 32-bit 393 integer. However, in the specific case of an IPFIX Mediator 394 containing an Intermediate Conversion Process, the IPFIX Mediator 395 MAY keep the export time received from the incoming Transport 396 Session. 398 Sequence Number: Incremental sequence counter modulo 2^32 of all 399 IPFIX Data Records sent in a the current stream from the current 400 Observation Domain by the Exporting Process. Each SCTP Stream 401 counts sequence numbers separately, while all messages in a TCP 402 connection or UDP transport session are considered to be part of 403 the same stream. This value SHOULD be used by the Collecting 404 Process to identify whether any IPFIX Data Records have been 405 missed. Template and Options Template Records do not increase the 406 Sequence Number. 408 Observation Domain ID: A 32-bit identifier of the Observation 409 Domain that is locally unique to the Exporting Process. The 410 Exporting Process uses the Observation Domain ID to uniquely 411 identify to the Collecting Process the Observation Domain that 412 metered the Flows. It is RECOMMENDED that this identifier should 413 be unique per IPFIX Device. Collecting Processes SHOULD use the 414 Transport Session and the Observation Domain ID field to separate 415 different export streams originating from the same Exporting 416 Process. The Observation Domain ID SHOULD be 0 when no specific 417 Observation Domain ID is relevant for the entire IPFIX Message. 418 For example, when exporting the Exporting Process Statistics, or 419 in case of hierarchy of Collector when aggregated Data Records are 420 exported. See Section 4.1 for special considerations for 421 Observation Domain management while passing unmodified templates 422 through a Mediator, and Section 5 for guidelines for preservation 423 of original Observation Domain information at a Mediator. 425 4. Template Management 427 How a Mediator handles the Templates it receives from the Original 428 Exporter depends entirely on the nature of the Intermediate Process 429 running on that Mediator. For Mediators which pass substantially the 430 same Data Records from the Original Exporter downstream, (e.g., an 431 Intermediate Selection Process), the templates can be passed 432 unmodified as described in Section 4.1; this section describes a 433 Template Mapping required to make this work in the general case. 434 Mediators which export Data Records which are substantially changed 435 from the Data Records received from the Original Exporter follow the 436 guidelines in Section 4.1 instead. 438 Subsequent subsections deal with specific issues in Template 439 management that may occur at Mediators. 441 4.1. Passing Unmodified Templates through a Mediator 443 [EDITOR'S NOTE: the definition of template mappings seems really 444 implementation specific -- why not notionally just map IDs on each 445 socket to a base template? on the other hand, if we're providing a 446 real example, it should have concrete content in each field. 447 reformatting is held off until this issue is resolved.] 449 The first case is a situation where the IPFIX Mediator doesn't modify 450 the (Options) Template Record(s) content. A typical example is an 451 Intermediate Selection Process acting as distributor, which collects 452 Flow Records from one or more Exporters, and based on the Information 453 Elements content, redirects the Flow Records to the appropriate 454 Collector. This example is a typical case of a single network 455 operation center managing multiple universities: an unique IPFIX 456 Collector collects all Flow Records for the common infrastructure, 457 but might be re-exporting specific university Flow Records to the 458 responsible system administrator. 460 As specified in [I-D.ietf-ipfix-protocol-rfc5101bis], the Template 461 IDs are unique per Exporter, per Transport Session, and per 462 Observation Domain. As there is no guarantee that, for similar 463 Template Records, the Template IDs received on the incoming Transport 464 Session and exported to the outgoing Transport Session would be same, 465 the IPFIX Mediator MUST maintain a Template Mapping composed of 466 related received and exported (Options) Template Records: 468 o for each received (Options) Template Record: Template Record Flow 469 Keys and non Flow Keys, Template ID, Observation Domain Id, and 470 Transport Session Information 472 o for each exported (Options) Template Record: Template Record Flow 473 Keys and non Flow Keys, Template ID, Collector, Observation Domain 474 Id, and Transport Session Information 476 If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 477 (Options) Template Record that is not used anymore in any other 478 Template Mappings, the IPFIX Mediator SHOULD export the appropriate 479 IPFIX Withdrawal Message(s) on the outgoing Transport Session, and 480 remove the corresponding entry in the Template Mapping. 482 If a (Options) Template Record is not used anymore in an outgoing 483 Transport Session, it MUST be withdrawn with an IPFIX Template 484 Withdrawal Message on that specific outgoing Transport Session, and 485 its entry MUST be removed from the Template Mapping. 487 If an incoming or outgoing Transport Session is gracefully shutdown 488 or reset, the (Options) Template Records corresponding to that 489 Transport Session MUST be removed from the Template Mapping. 491 For example, Figure 2 displays an example of an Intermediate 492 Selection Process, re-distributing Data Records to Collectors on the 493 basis of customer networks, i.e. the Route Distinguisher (RD). In 494 this example, the Template Record received from the Exporter #1 is 495 reused towards Collector #1, Collector #2, and Collector #3. 497 Tmpl. .---------. 498 ID 256 | | 499 .---->|Collector|<==>Customer 500 | |#1 | A 501 | | | 502 RD=100:1 '---------' 503 .---------.Templ. .---------. | 504 | |Id | |----' .---------. 505 | |258 | | RD=100:2 | | 506 |IPFIX |------->|IPFIX |--------->|Collector|<==>Customer 507 |Exporter | |Mediator | Tmpl. |#2 | B 508 |#1 | | | ID 257 | | 509 | | | |----. '---------' 510 '---------' '---------' | 511 RD=100:3 512 Tmpl. | .---------. 513 ID | | | 514 257 '---->|Collector|<==>Customer 515 |#3 | C 516 | | 517 '---------' 519 Figure 2: Intermediate Selection Process example 521 Figure 3 shows the Template Mapping for the system shown in Figure 2. 523 Template Entry A: 524 Incoming Transport Session Information (from Exporter#1): 525 Source IP: 526 Destination IP: 527 Protocol: SCTP 528 Source Port: 529 Destination Port: 4739 (IPFIX) 530 Observation Domain Id: 531 Template Id: 258 532 Flow Keys: 533 Non Flow Keys: 535 Template Entry B: 536 Outgoing Transport Session Information (to Collector#1): 537 Source IP: 538 Destination IP: 539 Protocol: SCTP 540 Source Port: 541 Destination Port: 4739 (IPFIX) 542 Observation Domain Id: 543 Template Id: 256 544 Flow Keys: 545 Non Flow Keys: 547 Template Entry C: 548 Outgoing Transport Session Information (to Collector#2): 549 Source IP: 550 Destination IP: 551 Protocol: SCTP 552 Source Port: 553 Destination Port: 4739 (IPFIX) 554 Observation Domain Id: 555 Template Id: 257 556 Flow Keys: 557 Non Flow Keys: 559 Template Entry D: 560 Outgoing Transport Session Information (to Collector#3): 561 Source IP: 562 Destination IP: 563 Protocol: SCTP 564 Source Port: 565 Destination Port: 4739 (IPFIX) 566 Observation Domain Id: 567 Template Id: 257 568 Flow Keys: 569 Non Flow Keys: 570 Figure 3: Template Mapping example: templates 572 The Template Mapping corresponding to figure B can be displayed as: 574 Template Entry A <----> Template Entry B 575 Template Entry A <----> Template Entry C 576 Template Entry A <----> Template Entry D 578 Template Mapping example: mappings 580 Alternatively, the Template Mapping may be optimized as: 582 +--> Template Entry B 583 | 584 Template Entry A <--+--> Template Entry C 585 | 586 +--> Template Entry D 588 Template Mapping example: mappings 590 Note that all examples use Transport Sessions based on the SCTP 591 protocol, as simplified use cases. However, the protocol would be 592 important in situations such as an Intermediate Conversion Process 593 doing transport protocol conversion. 595 4.2. Creating New Templates at a Mediator 597 The second case is a situation where the IPFIX Mediator generates new 598 (Options) Template Records as a result of the Intermediate Process. 600 In this situation, the IPFIX Mediator doesn't need to maintain a 601 Template Mapping, as it generates its own series of (Options) 602 Template Records. However, the following special case might still 603 require a Template Mapping, i.e. a situation where the IPFIX 604 Mediator, typically containing an Intermediate Conversion Process, 605 Intermediate Aggregation Process [I-D.ietf-ipfix-a9n], or 606 Intermediate Anonymization Process in case of black-marker 607 Anonymization [RFC6235], generates new (Options) Template Records 608 based on what it receives from the Exporter(s), and based on the 609 Intermediate Process function. In such a case, it's important to 610 keep the correlation between the received (Options) Template Records 611 and exported Derived (Options) Template Records in the Template 612 Mapping. These template mappings would be kept as in Section 4.1, 613 except that the export template would not be identical to the 614 collection template. 616 4.3. Information Element Ordering within Templates 618 [EDITOR'S NOTE: address the following: What Paul Aikten would like to 619 see in section 3.5 (See 620 http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html): 621 What about IE ordering? May an exporter re-order received fields? 622 eg, two devices sending the same information, though with the fields 623 in a different order. Or the mediator is extracting the same 624 information from two sources. That seems to be a valid scenario. eg, 625 this reduces the number of templates received at the collector.] 627 4.4. Handling Unknown Information Elements 629 [EDITOR'S NOTE: also from Paul Aitken: What should a mediator do with 630 a field which it doesn't know/understand? Inevitably, exporters will 631 be updated without mediators keeping in step. It's also very likely 632 that mediators will see Enterprise-specific IEs. May a mediator re- 633 export unknown IEs unchanged, or should it drop them? Presumably a 634 mediator may report received Enterprise-specific IEs even from 635 multiple different Enterprises. What if an unknown field depends on 636 the field ordering? eg, it's a bitfield like flowKeyIndicator. Re- 637 ordering, adding or removing fields breaks the meaning of this field, 638 so it can't be passed on. It can only be used if the received fields 639 are reported unchanged.] 641 5. Preserving Original Observation Point Information 643 [EDITOR'S NOTE: Decide whether we want to address export of 644 observation point information without 6313. Review this section to 645 make sure it adequately explains how original Observation Point 646 information can get so complicated.] 648 Depending on the use case, the Collector in an Exporter - Mediator - 649 Collector structure may need to receive information about the 650 Original Observation Point(s), otherwise it may wrongly conclude that 651 the IPFIX Device exporting the Flow Records, i.e. the IPFIX Mediator, 652 directly observed the packets that generated the Flow Records. Two 653 new Information Elements are introduced in the subsections below to 654 address this use case: originalExporterIPv4Address and 655 originalExporterIPv6Address. Practically, the Original Exporters 656 will not exporting these Information Elements. Therefore, the 657 Intermediate Process SHOULD report the Original Observation Point(s) 658 to the best of its knowledge. Note that the Configuration Data Model 659 for IPFIX and PSAMP [I-D.ietf-ipfix-configuration-model] may help. 661 In the IPFIX Mediator, the Observation Point(s) may be represented 662 by: 664 o A single Original Exporter (represented by the 665 originalExporterIPv4Address or originalExporterIPv6Address 666 Information Elements) 668 o A list of Original Exporters (represented by the 669 originalExporterIPv4Address or originalExporterIPv6Address 670 Information Elements). 672 o Any combination or list of Information Elements representing 673 Observation Points. For example: 675 * A list of Original Exporter interface(s) (represented by the 676 originalExporterIPv4Address or originalExporterIPv6Address, the 677 ingressInterface and/or egressInterface Information Elements, 678 respectively) 680 * A list of Original Exporter line card (represented by the 681 originalExporterIPv4Address or originalExporterIPv6Address, the 682 lineCardId Information Elements, respectively) 684 Some Information Elements characterizing the Observation Point may be 685 added. For example, the flowDirection Information Element specifies 686 the direction of the observation, and, as such, characterizes the 687 Observation Point. 689 Any combination of the above representations is possible. For 690 example, in case of an Intermediate Aggregation Process, an Original 691 Observation Point could be composed of: 693 exporterIPv4Address 192.0.2.1 694 exporterIPv4Address 192.0.2.2, 695 interface ethernet 0, direction ingress 696 interface ethernet 1, direction ingress 697 interface serial 1, direction egress 698 interface serial 2, direction egress 699 exporterIPv4Address 192.0.2.3, 700 lineCardId 1, direction ingress 702 Figure 4: Complex Observation Point Definition Example 704 If the Original Observation Point is composed of a list, then the 705 IPFIX Structured Data [RFC6313] MUST be used to export it from the 706 IPFIX Mediator. 708 The most generic way to export the Original Observation Point is to 709 use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking 710 the previous example, the following encoding can be used: 712 Template Record 257: exporterIPv4Address 713 Template Record 258: exporterIPv4Address, 714 basicList of ingressInterface, flowDirection 715 Template Record 259: exporterIPv4Address, lineCardId, flowDirection 717 Figure 5: Complex Observation Point Definition Example: Templates 719 The Original Observation Point is modeled with the Data Records 720 corresponding to either Template Record 1, Template Record 2, or 721 Template Record 3 but not more than one of these ("exactlyOneOf" 722 semantic). This implies that the Flow was observed at exactly one of 723 the Observation Points reported. 725 When an IPFIX Mediator receives Flow Records containing the Original 726 Observation Point Information Element, i.e. 727 originalExporterIPv6Address or originalExporterIPv4Address, the IPFIX 728 Mediator SHOULD NOT modify its value(s) when composing new Flow 729 Records in the general case. Known exceptions include anonymization 730 per [RFC6235] section 7.2.4 and an Intermediate Correlation Process 731 rewriting addresses across NAT. In other words, the Original 732 Observation Point should not be replaced with the IPFIX Mediator 733 Observation Point. The daisy chain of (Exporter, Observation Point) 734 representing the path the Flow Records took from the Exporter to the 735 top Collector in the Exporter - Mediator(s) - Collector structure 736 model is out of the scope of this specification. 738 5.1. originalExporterIPv4Address Information Element 740 Description: The IPv4 address used by the Exporting Process on an 741 Original Exporter, as seen by the Collecting Process on an IPFIX 742 Mediator. Used to provide information about the Original 743 Observation Points to a downstream Collector. 745 Data Type: ipv4Address 747 ElementId: TBD1 749 5.2. originalExporterIPv6Address Information Element 751 Description: The IPv6 address used by the Exporting Process on an 752 Original Exporter, as seen by the Collecting Process on an IPFIX 753 Mediator. Used to provide information about the Original 754 Observation Points to a downstream Collector. 756 Data Type: ipv6Address 757 ElementId: TBD2 759 6. Managing Observation Domain IDs 761 In any case, the Observation Domain ID of any IPFIX Message 762 containing Flow Records relevant to no particular Observation Domain, 763 or to multiple Observation Domains, MUST have an Observation Domain 764 ID of 0, as in Section 3 above, and section 3.1 of 765 [I-D.ietf-ipfix-protocol-rfc5101bis]. 767 IPFIX Mediators that do not change (Options) Template Records MUST 768 maintain a Template Mapping, as detailed in Section 4.1, to ensure 769 that the combination of Observation Domain IDs and Template IDs do 770 not collide on export. 772 For IPFIX Mediators that export New (Options) Template Records, as in 773 Section 4.2, there are two options for Observation Domain ID 774 management. The first and simplest of these is to completely 775 decouple exported Observation Domain IDs from received Observation 776 Domain IDs; the IPFIX Mediator, in this case, comprises its own set 777 of Observation Domain(s) independent of the Observation Domain(s) of 778 the Original Exporters. 780 The second option is to provide or maintain a Template Mapping for 781 received (Options) Template Records and exported inferred (Options) 782 Template Records, along with the appropriate Observation Domain IDs 783 per Transport Session, which ensures that the combination of 784 Observation Domain IDs and Template IDs do not collide on export. 786 In some cases where the IPFIX Message Header can't contain a 787 consistent Observation Domain for the entire IPFIX Message, but the 788 Flow Records exported from the IPFIX Mediator should anyway contain 789 the Observation Domain of the Original Exporter, the (Options) 790 Template Record must contain the originalObservationDomainId 791 Information Element. When an IPFIX Mediator receives Flow Records 792 containing the originalObservationDomainId Information Element, the 793 IPFIX Mediator MUST NOT modify its value(s) when composing new Flow 794 Records with the originalObservationDomainId Information Element. 796 6.1. originalObservationDomainId Information Element 798 Description: The Observation Domain ID reported by the Exporting 799 Process on an Original Exporter, as seen by the Collecting Process 800 on an IPFIX Mediator. Used to provide information about the 801 Original Observation Domain to a downstream Collector. 803 Data Type: unsigned32 805 Data Type Semantics: identifier 807 ElementId: TBD3 809 7. Timing Considerations 811 The IPFIX Message Header "Export Time" field is the time in seconds 812 since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the 813 IPFIX Mediator. However, in the specific case of an IPFIX Mediator 814 containing an Intermediate Conversion Process, the IPFIX Mediator MAY 815 keep the export time received from the incoming Transport Session. 817 It is RECOMMENDED that Mediators handle time using absolute 818 timestamps (e.g. flowStartSeconds, flowStartMilliseconds, 819 flowStartNanoseconds), which are specified relative to the UNIX epoch 820 (00:00 UTC 1 Jan 1970), where possible, rather than relative 821 timestamps (e.g. flowStartSysUpTime, flowStartDeltaMicroseconds), 822 which are specified relative to protocol structures such as system 823 initialization or message export time. 825 The latter are difficult to manage for two reasons. First, they 826 require constant translation, as the system initialization time of an 827 intermediate system and the export time of an intermediate message 828 will change across mediation operations. Further, relative 829 timestamps introduce range problems. For example, when using the 830 flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information 831 Elements [iana-ipfix-assignments], the Data Record must be exported 832 within a maximum of 71 minutes after its creation. Otherwise, the 833 32-bit counter would not be sufficient to contain the flow start time 834 offset. Those time constraints might be incompatible with some of 835 the application requirements of some Intermediate Processes. 837 Intermediate Processes MUST NOT assume that received records appear 838 in flowStartTime, flowEndTime, or observationTime order. An 839 Intermediate Process processing timing information (e.g., an 840 Intermediate Aggregation Process) MAY ignore records that are 841 significantly out of order, in order to meet application-specific 842 state and latency requirements, but SHOULD report that records were 843 dropped. 845 When an Intermediate Process aggregates information from different 846 Flow Records, the timestamps on exported records SHOULD be the 847 minimum of the start times and the maximum of the end times in the 848 general case. However, if the Flow Records do not overlap, i.e. if 849 there is a time gap between the times in the Flow Records, then the 850 report may be inaccurate. The IPFIX Mediator is only reporting what 851 it knows, on the basis of the information made available to it - and 852 there may not have been any data to observe during the gap. Then 853 again, if there is an overlap in timestamps, there's the potential of 854 double-accounting: different Observation Points may have observed the 855 same traffic simultaneously. Therefore, as there is not a single 856 rule that fits all different situations, a complete specification of 857 the precise rules of applying Flow Record timestamps at IPFIX 858 Mediators is out of the scope of this document. 860 Note that [I-D.ietf-ipfix-a9n] provides additional specifications for 861 handling of timestamps at an Intermediate Aggregation Process. 863 8. Transport Considerations 865 SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] 866 MUST be implemented by all compliant IPFIX Mediator implementations. 867 TCP [RFC0793] MAY also be implemented by IPFIX Mediator compliant 868 implementations. UDP [RFC0768] MAY also be implemented by compliant 869 IPFIX Mediator implementations. Transport-specific considerations 870 for IPFIX Exporters as specified in sections 8.3, 8.4, 9.1, 9.2, and 871 10 of [I-D.ietf-ipfix-protocol-rfc5101bis] apply to IPFIX Mediators 872 as well. 874 SCTP SHOULD be used in deployments where IPFIX Mediators and 875 Collectors are communicating over links that are susceptible to 876 congestion. SCTP is capable of providing any required degree of 877 reliability. TCP MAY be used in deployments where IPFIX Mediators 878 and Collectors communicate over links that are susceptible to 879 congestion, but SCTP is preferred due to its ability to limit back 880 pressure on Exporters and its message versus stream orientation. UDP 881 MAY be used, although it is not a congestion-aware protocol. 882 However, in this case, the IPFIX traffic between IPFIX Mediator and 883 Collector MUST run in an environment where IPFIX traffic has been 884 provisioned for, or is contained through some other means. 886 9. Collecting Process Considerations 888 Any Collecting Process compliant with 889 [I-D.ietf-ipfix-protocol-rfc5101bis] can receive IPFIX Messages from 890 an IPFIX Mediator. If the IPFIX Mediator uses IPFIX Structured Data 891 [RFC6313] to export Original Exporter Information as in Section 5, 892 the Collecting Process MUST support [RFC6313]. 894 10. Specific Reporting Requirements 896 IPFIX provides Options Templates for the reporting on the reliability 897 of processes within the IPFIX Architecture. As each Mediator 898 includes at least one IPFIX Exporting Process, they SHOULD use the 899 Exporting Process Reliability Statistics Options Template, as 900 specified in [I-D.ietf-ipfix-protocol-rfc5101bis]. 902 Analogous to the Metering Process Reliability Statistics Options 903 Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], 904 Mediators SHOULD implement the Intermediate Process Reliability 905 Statistics Options Template, specified in the subsection below. 907 The Flow Keys Options Template, as specified in 908 [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at 909 an IPFIX Mediator as described below. 911 In addition, each Intermediate Process may have its own specific 912 reporting requirements (e.g. Anonymization Records as in [RFC6235], 913 or the Aggregation Counter Distribution Options Template as in 914 [I-D.ietf-ipfix-a9n]); these SHOULD be implemented as necessary as 915 described in the specification for each Intermediate Process. 917 10.1. Intermediate Process Reliability Statistics Template 919 The Intermediate Process Statistics Options Template specifies the 920 structure of a Data Record for reporting Intermediate Process 921 statistics. It SHOULD contain the following Information Elements; 922 the intermediateProcessId Information Element is defined in 923 Section 10.3, and the ignoredRecordTotalCount Information Element is 924 defined in Section 10.4: 926 +-------------------------+-----------------------------------------+ 927 | IE | Description | 928 +-------------------------+-----------------------------------------+ 929 | observationDomainId | An identifier of the Observation Domain | 930 | [scope] | (of messages exported by this | 931 | | Mediator), locally unique to the | 932 | | Intermediate Process, to which this | 933 | | statistics record applies. | 934 | intermediateProcessId | An identifier for the Intermediate | 935 | [scope] | Process to which this statistics record | 936 | | applies. | 937 | ignoredRecordTotalCount | The total number of Data Records | 938 | | received but not processed by the | 939 | | Intermediate Process. | 940 | time first record | The timestamp of the first record that | 941 | ignored | was ignored by the Intermediate | 942 | | Process. For Data Records containing | 943 | | timestamp ranges, this SHOULD be taken | 944 | | from the start timestamp of the range; | 945 | | for data records containing no timing | 946 | | information, this SHOULD be taken from | 947 | | the Export Time in the message header | 948 | | of the containing IPFIX Message. For | 949 | | this timestamp, any of the following | 950 | | timestamp can be used: | 951 | | observationTimeSeconds, | 952 | | observationTimeMilliseconds, | 953 | | observationTimeMicroseconds, or | 954 | | observationTimeNanoseconds. | 955 | time last record | The timestamp of the last record that | 956 | ignored | was ignored by the Intermediate | 957 | | Process. For Data Records containing | 958 | | timestamp ranges, this SHOULD be taken | 959 | | from the end timestamp of the range; | 960 | | for data records containing no timing | 961 | | information, this SHOULD be taken from | 962 | | the Export Time in the message header | 963 | | of the containing IPFIX Message. For | 964 | | this timestamp, any of the following | 965 | | timestamp can be used: | 966 | | observationTimeSeconds, | 967 | | observationTimeMilliseconds, | 968 | | observationTimeMicroseconds, or | 969 | | observationTimeNanoseconds. | 970 +-------------------------+-----------------------------------------+ 972 10.2. Flow Key Options Template 974 The Flow Keys Option Template specifies the structure of a Data 975 Record for reporting the Flow Keys of reported Flows. A Flow Keys 976 Data Record extends a particular Template Record that is referenced 977 by its templateId identifier. The Template Record is extended by 978 specifying which of the Information Elements contained in the 979 corresponding Data Records describe Flow properties that serve as 980 Flow Keys of the reported Flow. This Options Template is defined in 981 section 4.4 of [I-D.ietf-ipfix-protocol-rfc5101bis], and SHOULD be 982 used by Mediators for export as defined there. 984 When an Intermediate Process exports Data Records containing 985 different Flow Keys from those received from the Original Exporter, 986 and the Original Exporter sent a Flow Keys Options record to the 987 Mediator, the Mediator MUST export a Flow Keys Options record 988 defining the the new set of Flow Keys. 990 10.3. intermediateProcessId Information Element 992 Description: An identifier of an Intermediate Process that is 993 unique per IPFIX Device. Typically, this Information Element is 994 used for limiting the scope of other Information Elements. Note 995 that process identifiers may be assigned dynamically; ie., and 996 Intermediate Process may be re-started with a different ID. 998 Data Type: unsigned32 1000 Data Type Semantics: identifier 1002 ElementId: TBD4 1004 10.4. ignoredRecordTotalCount Information Element 1006 Description: The total number of received Data Records that the 1007 Intermediate Process did not process since the (re-)initialization 1008 of the Intermediate Process; includes only Data Records not 1009 examined or otherwise handled by the Intermediate Process due to 1010 resource constraints, not Data Records which were examined or 1011 otherwise handled by the Intermediate Process but which merely do 1012 not contribute to any exported Data Record due to the operations 1013 performed by the Intermediate Process. 1015 Data Type: unsigned64 1017 Data Type Semantics: totalCounter 1019 ElementId: TBD5 1021 11. Configuration Management 1023 In general, using Mediators to combine information from multiple 1024 Original Exporters requires a consistent configuration of the 1025 Metering Processes behind these Original Exporters. The details of 1026 this consistency are specific to each Intermediate Process. 1027 Consistency of configuration should be verified out of band, with the 1028 MIB modules ([I-D.ietf-ipfix-rfc5815bis] and 1029 [I-D.ietf-ipfix-psamp-mib]) or with the Configuration Data Model for 1030 IPFIX and PSAMP [I-D.ietf-ipfix-configuration-model] 1032 12. Security Considerations 1034 As they act as both IPFIX Collecting Processes and Exporting 1035 Processes, the Security Considerations for IPFIX Protocol 1036 [I-D.ietf-ipfix-protocol-rfc5101bis] also apply to Mediators. The 1037 Security Considerations for IPFIX Files [RFC5655] also apply to IPFIX 1038 Mediators that write IPFIX Files or use them for internal storage. 1039 However, there are a few specific considerations that IPFIX Mediator 1040 implementations must also take into account. 1042 By design, IPFIX Mediators are "men-in-the-middle": they intercede in 1043 the communication between an Original Exporter (or another upstream 1044 Mediator) and a downstream Collecting Process. This has two 1045 important implications for the level of confidentiality provided 1046 across an IPFIX Mediator, and the ability to protect data integrity 1047 and Original Exporter authenticity across a Mediator. These are 1048 addressed in more detail in the Security Considerations for Mediators 1049 in [RFC6183]. 1051 Note that, while Mediators can use the exporterCertificate and 1052 collectorCertificate Information Elements defined in [RFC5655] as 1053 described in section 9.3 of [RFC6183] to export information about 1054 X.509 identities in upstream TLS-protected Transport Sessions, this 1055 mechanism cannot be used to provide true end-to-end assertions about 1056 a chain of IPFIX Mediators: any Mediator in the chain can simply 1057 falsify the information about upstream Transport Sessions In 1058 situations where information about the chain of mediation is 1059 important, it must be determined out of band. 1061 13. IANA Considerations 1063 This document specifies n new IPFIX Information Elements, 1064 originalExporterIPv4Address in Section 5.1, 1065 originalExporterIPv6Address in Section 5.2, and 1066 originalObservationDomainId in Section 6.1, to be added to the IPFIX 1067 Information Element registry [iana-ipfix-assignments]. [IANA NOTE: 1068 please add the three Information Elements as specified in the 1069 references subsections, and change TBD1, TBD2, and TBD3 in this 1070 document to reflect the assigned identifiers.] 1072 14. Acknowledgments 1074 We would like to thank the IPFIX contributors, specifically Paul 1075 Aitken for his thorough review and Rahul Patel for his feedback and 1076 comments. This work is materially supported by the European Union 1077 Seventh Framework Programme under grant agreement 257315 (DEMONS). 1079 15. References 1081 15.1. Normative References 1083 [I-D.ietf-ipfix-protocol-rfc5101bis] 1084 Claise, B. and B. Trammell, "Specification of the IP Flow 1085 Information eXport (IPFIX) Protocol for the Exchange of 1086 Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-02 1087 (work in progress), June 2012. 1089 [I-D.ietf-ipfix-information-model-rfc5102bis] 1090 Claise, B. and B. Trammell, "Information Model for IP Flow 1091 Information eXport (IPFIX)", 1092 draft-ietf-ipfix-information-model-rfc5102bis-02 (work in 1093 progress), June 2012. 1095 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1096 August 1980. 1098 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1099 RFC 793, September 1981. 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1104 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1105 Conrad, "Stream Control Transmission Protocol (SCTP) 1106 Partial Reliability Extension", RFC 3758, May 2004. 1108 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1109 RFC 4960, September 2007. 1111 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 1112 Wagner, "Specification of the IP Flow Information Export 1113 (IPFIX) File Format", RFC 5655, October 2009. 1115 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 1116 "Export of Structured Data in IP Flow Information Export 1117 (IPFIX)", RFC 6313, July 2011. 1119 [I-D.ietf-ipfix-flow-selection-tech] 1120 D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 1121 Selection Techniques", 1122 draft-ietf-ipfix-flow-selection-tech-11 (work in 1123 progress), April 2012. 1125 [I-D.ietf-ipfix-a9n] 1126 Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation 1127 for the IP Flow Information Export (IPFIX) Protocol", 1128 draft-ietf-ipfix-a9n-05 (work in progress), July 2012. 1130 [I-D.ietf-ipfix-psamp-mib] 1131 Dietz, T., Claise, B., and J. Quittek, "Definitions of 1132 Managed Objects for Packet Sampling", 1133 draft-ietf-ipfix-psamp-mib-05 (work in progress), 1134 July 2012. 1136 [I-D.ietf-ipfix-configuration-model] 1137 Muenz, G., Claise, B., and P. Aitken, "Configuration Data 1138 Model for IPFIX and PSAMP", 1139 draft-ietf-ipfix-configuration-model-11 (work in 1140 progress), June 2012. 1142 [I-D.ietf-ipfix-rfc5815bis] 1143 Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 1144 "Definitions of Managed Objects for IP Flow Information 1145 Export", draft-ietf-ipfix-rfc5815bis-03 (work in 1146 progress), March 2012. 1148 15.2. Informative References 1150 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1151 "Requirements for IP Flow Information Export (IPFIX)", 1152 RFC 3917, October 2004. 1154 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1155 9", RFC 3954, October 2004. 1157 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1158 "Architecture for IP Flow Information Export", RFC 5470, 1159 March 2009. 1161 [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP 1162 Flow Information Export (IPFIX) Applicability", RFC 5472, 1163 March 2009. 1165 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling 1166 (PSAMP) Protocol Specifications", RFC 5476, March 2009. 1168 [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export 1169 (IPFIX) Mediation: Problem Statement", RFC 5982, 1170 August 2010. 1172 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1173 "IP Flow Information Export (IPFIX) Mediation: Framework", 1174 RFC 6183, April 2011. 1176 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1177 Support", RFC 6235, May 2011. 1179 [iana-ipfix-assignments] 1180 Internet Assigned Numbers Authority, "IP Flow Information 1181 Export Information Elements 1182 (http://www.iana.org/assignments/ipfix/ipfix.xml)". 1184 [POSIX.1] IEEE, "IEEE 1003.1-2008 - IEEE Standard for Information 1185 Technology - Portable Operating System Interface". 1187 Authors' Addresses 1189 Benoit Claise 1190 Cisco Systems, Inc. 1191 De Kleetlaan 6a b1 1192 1831 Diagem 1193 Belgium 1195 Phone: +32 2 704 5622 1196 Email: bclaise@cisco.com 1198 Atsushi Kobayashi 1199 NTT Information Sharing Platform Laboratories 1200 3-9-11 Midori-cho 1201 Musashino-shi, Tokyo 180-8585 1202 Japan 1204 Phone: +81 422 59 3978 1205 Email: akoba@nttv6.net 1207 Brian Trammell 1208 Swiss Federal Institute of Technology Zurich 1209 Gloriastrasse 35 1210 8092 Zurich 1211 Switzerland 1213 Phone: +41 44 632 70 13 1214 Email: trammell@tik.ee.ethz.ch