summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7119.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7119.txt')
-rw-r--r--doc/rfc/rfc7119.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc7119.txt b/doc/rfc/rfc7119.txt
new file mode 100644
index 0000000..d3cf323
--- /dev/null
+++ b/doc/rfc/rfc7119.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Claise
+Request for Comments: 7119 Cisco Systems, Inc.
+Category: Standards Track A. Kobayashi
+ISSN: 2070-1721 NTT
+ B. Trammell
+ ETH Zurich
+ February 2014
+
+
+ Operation of the IP Flow Information Export (IPFIX) Protocol
+ on IPFIX Mediators
+
+Abstract
+
+ This document specifies the operation of the IP Flow Information
+ Export (IPFIX) protocol specific to IPFIX Mediators, including
+ Template and Observation Point management, timing considerations, and
+ other Mediator-specific concerns.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7119.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Claise, et al. Standards Track [Page 1]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. IPFIX Documents Overview ...................................3
+ 1.2. IPFIX Mediator Documents Overview ..........................4
+ 1.3. Relationship with the IPFIX and PSAMP Protocols ............5
+ 2. Terminology .....................................................5
+ 3. Handling IPFIX Message Headers ..................................8
+ 4. Template Management ............................................10
+ 4.1. Passing Unmodified Templates through an IPFIX Mediator ....11
+ 4.1.1. Template Mapping and Information Element Ordering ..15
+ 4.2. Creating New Templates at an IPFIX Mediator ...............17
+ 4.3. Handling Unknown Information Elements .....................17
+ 5. Preserving Original Observation Point Information ..............17
+ 5.1. originalExporterIPv4Address Information Element ...........20
+ 5.2. originalExporterIPv6Address Information Element ...........20
+ 6. Managing Observation Domain IDs ................................20
+ 6.1. originalObservationDomainId Information Element ...........21
+ 7. Timing Considerations ..........................................21
+ 8. Transport Considerations .......................................23
+ 9. Collecting Process Considerations ..............................23
+ 10. Specific Reporting Requirements ...............................23
+ 10.1. Intermediate Process Reliability Statistics
+ Options Template .........................................24
+ 10.2. Flow Key Options Template ................................26
+ 10.3. intermediateProcessId Information Element ................26
+ 10.4. ignoredDataRecordTotalCount Information Element ..........27
+ 11. Operations and Management Considerations ......................27
+ 12. Security Considerations .......................................28
+ 13. IANA Considerations ...........................................28
+ 14. Acknowledgments ...............................................29
+ 15. References ....................................................29
+ 15.1. Normative References .....................................29
+ 15.2. Informative References ...................................30
+
+1. Introduction
+
+ The IPFIX architectural components in [RFC5470] consist of IPFIX
+ Devices and IPFIX Collectors communicating using the IPFIX protocol
+ [RFC7011], which specifies how to export IP Flow information. This
+ protocol is designed to export information about IP traffic Flows and
+ related measurement data, where a Flow is defined by a set of key
+ attributes (e.g., source and destination IP address, source and
+ destination port, etc.).
+
+ However, thanks to its Template mechanism, the IPFIX protocol can
+ export any type of information, as long as the relevant Information
+ Element is specified in the IPFIX Information Model [RFC7012],
+
+
+
+Claise, et al. Standards Track [Page 2]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ registered with IANA, or specified as an enterprise-specific
+ Information Element. The IPFIX protocol [RFC7011] was not originally
+ written with IPFIX Mediators in mind. Therefore, the IPFIX protocol
+ must be adapted for Intermediate Processes, as defined in the IPFIX
+ Mediation Reference Model as specified in Figure A of [RFC6183],
+ which is based on the IPFIX Mediation Problem Statement [RFC5982].
+
+ This document specifies the IP Flow Information Export (IPFIX)
+ protocol in the context of the implementation and deployment of IPFIX
+ Mediators. The use of the IPFIX protocol within an IPFIX Mediator --
+ a device that contains both a Collecting Process and an Exporting
+ Process -- has an impact on the technical details of the usage of the
+ protocol. An overview of the technical problem is covered in
+ Section 6 of [RFC5982]: loss of original Exporter information, loss
+ of base time information, transport sessions management, loss of
+ Options Template Information, Template Id management, considerations
+ for network topology, IPFIX mediation interpretation, and
+ considerations for aggregation.
+
+ The specifications in this document are based on the IPFIX protocol
+ specifications [RFC7011], but they are adapted according to the IPFIX
+ Mediation Framework [RFC6183].
+
+1.1. IPFIX Documents Overview
+
+ The IPFIX protocol [RFC7011] provides network administrators with
+ access to IP Flow information.
+
+ The architecture for the export of measured IP Flow information out
+ of an IPFIX Exporting Process to a Collecting Process is defined in
+ the IPFIX Architecture [RFC5470], per the requirements defined in the
+ IPFIX Requirements document, [RFC3917].
+
+ The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and
+ Templates are carried via a congestion-aware transport protocol from
+ IPFIX Exporting Processes to IPFIX Collecting Processes.
+
+ IPFIX has a formal description of IPFIX Information Elements, their
+ names, types, and additional semantic information, as specified in
+ the IPFIX Information Model [RFC7012]. The IPFIX Information Element
+ registry [IANA-IPFIX] is maintained by IANA. New Information Element
+ definitions can be added to this registry subject to an Expert Review
+ [RFC5226], with additional process considerations described in
+ [RFC7013]; that document also provides guidelines for authors and
+ reviewers of new Information Element definitions. The inline export
+ of the Information Element type information is specified in
+ [RFC5610].
+
+
+
+
+Claise, et al. Standards Track [Page 3]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ The IPFIX Applicability Statement [RFC5472] describes what type of
+ applications can use the IPFIX protocol and how they can use the
+ information provided. It furthermore shows how the IPFIX framework
+ relates to other architectures and frameworks.
+
+1.2. IPFIX Mediator Documents Overview
+
+ "IP Flow Information Export (IPFIX) Mediation: Problem Statement"
+ [RFC5982] provides an overview of the applicability of IPFIX
+ Mediators and defines requirements for IPFIX Mediators in general
+ terms. This document is of use largely to define the problems to be
+ solved through the deployment of IPFIX Mediators and to provide scope
+ to the role of IPFIX Mediators within an IPFIX collection
+ infrastructure.
+
+ "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183],
+ which details the IPFIX Mediation reference model and the components
+ of an IPFIX Mediator, provides more architectural details of the
+ arrangement of Intermediate Processes within an IPFIX Mediator.
+
+ Documents specifying the operations of specific Intermediate
+ Processes cover the operation of these Processes within the IPFIX
+ Mediator framework and comply with the specifications given in this
+ document; additionally, they may specify the operation of the process
+ independently, outside the context of an IPFIX Mediator, when this is
+ appropriate. The details of specific Intermediate Processes, when
+ they have additional export specifications (e.g., metadata about the
+ intermediate processing conveyed through IPFIX Options Templates),
+ are each addressed in their own document. As of today, these
+ documents are:
+
+ 1. "IP Flow Anonymization Support", [RFC6235], which describes
+ anonymization techniques for IP flow data and the export of
+ anonymized data using the IPFIX protocol.
+
+ 2. "Flow Selection Techniques" [RFC7014], which describes the
+ process of selecting a subset of Flows from all Flows observed at
+ an Observation Point, the flow selection motivations, and some
+ specific flow selection techniques.
+
+ 3. "Flow Aggregation for the IP Flow Information Export (IPFIX)
+ Protocol" [RFC7015], which describes Aggregated Flow export
+ within the framework of IPFIX Mediators and defines an
+ interoperable, implementation-independent method for Aggregated
+ Flow export.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 4]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ This document specifies the IP Flow Information Export (IPFIX)
+ protocol specific to Mediation, to which all Intermediate Processes
+ must comply. Some extra specifications might be required per
+ Intermediate Process type (in which case, the document specific to
+ the Intermediate Process would apply).
+
+1.3. Relationship with the IPFIX and PSAMP Protocols
+
+ The specification in this document is based on the IPFIX protocol
+ specification [RFC7011]. All specifications from [RFC7011] apply
+ unless specified otherwise in this document.
+
+ As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are
+ based on the IPFIX protocol specifications, the specifications in
+ this document are also valid for the PSAMP protocol. Therefore, the
+ method specified by this document also applies to PSAMP.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ IPFIX-specific terms, such as Observation Domain, Flow, Flow Key,
+ Metering Process, Exporting Process, Exporter, IPFIX Device,
+ Collecting Process, Collector, Template, IPFIX Message, Message
+ Header, Template Record, Data Record, Options Template Record, Set,
+ Data Set, Information Element, Scope and Transport Session, used in
+ this document are defined in [RFC7011]. The PSAMP-specific terms
+ used in this document, such as Filtering and Sampling, are defined in
+ [RFC5476].
+
+ IPFIX Mediation terms related to aggregation, such as the Interval,
+ Aggregated Flow and Aggregated Function, are defined in [RFC7015].
+
+ The terminology specific to IPFIX Mediation that is used in this
+ document is defined in "IP Flow Information Export (IPFIX) Mediation:
+ Problem Statement" [RFC5982] and reused in "IP Flow Information
+ Export (IPFIX) Mediation: Framework" [RFC6183]. However, since both
+ of those documents are Informational RFCs, the definitions have been
+ reproduced and elaborated on here.
+
+ Similarly, since [RFC6235] is an Experimental RFC, the Anonymization
+ Record, Anonymized Data Record, and Intermediate Anonymization
+ Process terms, specified in [RFC6235], are also reproduced here.
+
+
+
+
+
+Claise, et al. Standards Track [Page 5]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ In this document, as in [RFC7011], [RFC5476], [RFC7015], and
+ [RFC6235], the first letter of each IPFIX-specific and PSAMP-specific
+ term is capitalized along with the IPFIX Mediation-specific term
+ defined here.
+
+ In this document, we call a stream of records carrying flow- or
+ packet-based information a "record stream". The records may be
+ encoded as IPFIX Data Records or any other format.
+
+ Transport Session: The Transport Session is specified in [RFC7011].
+ In Stream Control Transmission Protocol (SCTP), the Transport
+ Session information is the SCTP association. In TCP and UDP, the
+ Transport Session information corresponds to a 5-tuple {Exporter
+ IP address, Collector IP address, Exporter transport port,
+ Collector transport port, transport protocol}.
+
+ Original Exporter: An Original Exporter is the source from which a
+ Mediator receives its record stream. For simple IPFIX mediation
+ without protocol conversion, this is an IPFIX Device that hosts
+ the Observation Points where the metered IP packets are observed.
+
+ Original Observation Point: An Observation Point on a Metering
+ Process associated with the Original Exporter. In the case of the
+ Intermediate Aggregation Process on an IPFIX Mediator, the
+ Original Observation Point can be composed of, but not limited to,
+ a (set of) specific Exporter(s), a (set of) specific interface(s)
+ on an Exporter, a (set of) line card(s) on an Exporter, or any
+ combinations of these.
+
+ IPFIX Mediation: IPFIX Mediation is the manipulation and conversion
+ of a record stream for subsequent export using the IPFIX protocol.
+
+ Template Mapping: A mapping from Template Records and/or Options
+ Template Records received by an IPFIX Mediator to Template Records
+ and/or Options Template Records sent by that IPFIX Mediator. Each
+ entry in a Template Mapping is scoped by incoming or outgoing
+ Transport Session and Observation Domain, as with Templates and
+ Options Templates in the IPFIX Protocol.
+
+ Anonymization Record: A record that defines the properties of the
+ anonymization applied to a single Information Element within a
+ single Template or Options Template, as in [RFC6235].
+
+ Anonymized Data Record: A Data Record within a Data Set containing
+ at least one Information Element with anonymized values. The
+ Information Element(s) within the Template or Options Template
+ describing this Data Record SHOULD have a corresponding
+ Anonymization Record, as in [RFC6235].
+
+
+
+Claise, et al. Standards Track [Page 6]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ The following terms are used in this document to describe the
+ architectural entities used by IPFIX Mediation.
+
+ Intermediate Process: An Intermediate Process takes a record stream
+ as its input from Collecting Processes, Metering Processes, IPFIX
+ File Readers, other Intermediate Processes, or other record
+ sources; performs some transformations on this stream, based upon
+ the content of each record, states maintained across multiple
+ records, or other data sources; and passes the transformed record
+ stream as its output to Exporting Processes, IPFIX File Writers,
+ or other Intermediate Processes, in order to perform IPFIX
+ Mediation. Typically, an Intermediate Process is hosted by an
+ IPFIX Mediator. Alternatively, an Intermediate Process may be
+ hosted by an Original Exporter.
+
+ IPFIX Mediator: An IPFIX Mediator is an IPFIX Device that provides
+ IPFIX Mediation by receiving a record stream from some data
+ sources, hosting one or more Intermediate Processes to transform
+ that stream, and exporting the transformed record stream into
+ IPFIX Messages via an Exporting Process. In the common case, an
+ IPFIX Mediator receives a record stream from a Collecting Process,
+ but it could also receive a record stream from data sources not
+ encoded using IPFIX, e.g., in the case of conversion from the
+ NetFlow V9 protocol [RFC3954] to IPFIX protocol.
+
+ Specific Intermediate Processes are described below.
+
+ Intermediate Conversion Process (as in [RFC6183]): An Intermediate
+ Conversion Process is an Intermediate Process that transforms non-
+ IPFIX into IPFIX or manages the relation among Templates and
+ states of incoming/outgoing Transport Sessions in the case of
+ transport protocol conversion (e.g., from UDP to SCTP).
+
+ Intermediate Aggregation Process (as in [RFC7015]): an Intermediate
+ Process (IAP), as in [RFC6183], that aggregates records, based
+ upon a set of Flow Keys or functions applied to fields from the
+ record.
+
+ Intermediate Correlation Process (as in [RFC6183]): An Intermediate
+ Correlation Process is an Intermediate Process that adds
+ information to records, noting correlations among them, or
+ generates new records with correlated data from multiple records
+ (e.g., the production of bidirectional flow records from
+ unidirectional flow records).
+
+ Intermediate Anonymization Process (as in [RFC6235]): An
+ intermediate process that takes Data Records and transforms them
+ into Anonymized Data Records.
+
+
+
+Claise, et al. Standards Track [Page 7]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ Intermediate Selection Process (as in [RFC6183]): An Intermediate
+ Selection Process is an Intermediate Process that selects records
+ from a sequence based upon criteria-evaluated record values and
+ passes only those records that match the criteria (e.g., Filtering
+ only records from a given network to a given Collector).
+
+ Intermediate Flow Selection Process (as in [RFC7014]: An
+ Intermediate Flow Selection Process is an Intermediate Process, as
+ in [RFC6183] that takes Flow Records as its input and selects a
+ subset of this set as its output. The Intermediate Flow Selection
+ Process is a more general concept than the Intermediate Selection
+ Process as defined in [RFC6183]. While an Intermediate Selection
+ Process selects Flow Records from a sequence based upon criteria-
+ evaluated Flow record values and only passes on those Flow Records
+ that match the criteria, an Intermediate Flow Selection Process
+ selects Flow Records using selection criteria applicable to a
+ larger set of Flow characteristics and information.
+
+ Note: for more information on the difference between Intermediate
+ Flow Selection Process and Intermediate Selection Process, see
+ Section 4 in [RFC7014].
+
+3. Handling IPFIX Message Headers
+
+ The format of the IPFIX Message Header as exported by an IPFIX
+ Mediator is shown in Figure 1. This is identical to the format
+ defined for IPFIX in [RFC7011], though Export Time and Observation
+ Domain ID may be handled differently at certain Mediators, as noted
+ below.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Export Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Observation Domain ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: IPFIX Message Header format
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 8]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ The header fields as exported by an IPFIX Mediator are described
+ below.
+
+ Version:
+
+ Version of IPFIX to which this Message conforms. The value of
+ this field is 0x000a for the current version, incrementing by one
+ the version used in the NetFlow services export version 9
+ [RFC3954].
+
+ Length:
+
+ Total length of the IPFIX Message, measured in octets, including
+ Message Header and Set(s).
+
+ Export Time:
+
+ Time at which the IPFIX Message Header leaves the IPFIX Mediator,
+ expressed in seconds since the UNIX epoch of 1 January 1970 at
+ 00:00 UTC, encoded as an unsigned 32-bit integer.
+
+ However, in the specific case of an IPFIX Mediator containing an
+ Intermediate Conversion Process, the IPFIX Mediator MAY use the
+ export time received from the incoming Transport Session.
+
+ Sequence Number:
+
+ Incremental sequence counter modulo 2^32 of all IPFIX Data Records
+ sent in the current stream from the current Observation Domain by
+ the Exporting Process. Each SCTP Stream counts sequence numbers
+ separately, while all messages in a TCP connection or UDP
+ Transport Session are considered to be part of the same stream.
+ This value can be used by the Collecting Process to identify
+ whether any IPFIX Data Records have been missed. Template and
+ Options Template Records do not increase the Sequence Number.
+
+ Observation Domain ID:
+
+ A 32-bit identifier of the Observation Domain that is locally
+ unique to the Exporting Process. The Exporting Process uses the
+ Observation Domain ID to uniquely identify to the Collecting
+ Process the Observation Domain that metered the Flows. It is
+ RECOMMENDED that this identifier also be unique per IPFIX Device.
+ Collecting Processes can use the Transport Session and the
+ Observation Domain ID field to separate different export streams
+ originating from the same Exporter. The Observation Domain ID is
+ set to 0 when no specific Observation Domain ID is relevant for
+
+
+
+
+Claise, et al. Standards Track [Page 9]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ the entire IPFIX Message, for example, when exporting the
+ Exporting Process Statistics, or in case of a hierarchy of
+ Collectors when aggregated Data Records are exported.
+
+ See Section 4.1 for special considerations for Observation Domain
+ management while passing unmodified templates through an IPFIX
+ Mediator, and Section 5 for guidelines for preservation of
+ original Observation Domain information at an IPFIX Mediator.
+
+ The following specifications, copied over from [RFC7011] have some
+ implications in this document:
+
+ Template Withdrawals MAY appear interleaved with Template Sets,
+ Options Template Sets, and Data Sets within an IPFIX Message. In
+ this case, the Templates and Template Withdrawals shall be
+ interpreted as taking effect in the order in which they appear in
+ the IPFIX Message.
+
+ If an IPFIX Mediator receives an IPFIX Message composed of Template
+ Withdrawals and Template Sets, and if the IPFIX Mediator forwards
+ this IPFIX Message, it MUST NOT modify the Set order. If an IPFIX
+ Mediator receives IPFIX Messages composed of Template Withdrawals and
+ Template Sets, and if the IPFIX Mediator forwards these IPFIX
+ Messages, it MUST NOT modify the IPFIX Message order. Note that the
+ Template Mapping (see Section 4.1) is the authoritative source of
+ information on the IPFIX Mediator to decide whether the entire IPFIX
+ Messages can be forwarded as such.
+
+4. Template Management
+
+ How an IPFIX Mediator handles the Templates it receives from the
+ Original Exporter depends entirely on the nature of the Intermediate
+ Process running on that IPFIX Mediator. There are two cases here:
+
+ 1. IPFIX Mediators that pass substantially the same Data Records
+ from the Original Exporter downstream (e.g., an Intermediate
+ Selection Process), pass unmodified Templates as described in
+ Section 4.1; this section describes a Template Mapping required
+ to make this work in the general case, and the correlation
+ between the received and generated IPFIX Message Withdrawals.
+
+ 2. IPFIX Mediators that export Data Records that are substantially
+ changed from the Data Records received from the Original Exporter
+ follow the guidelines in Section 4.2 instead: in this case, the
+ IPFIX Mediator generates new (Options) Template Records as a
+ result of the Intermediate Process, and no Template Mapping is
+ required.
+
+
+
+
+Claise, et al. Standards Track [Page 10]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ Subsequent subsections deal with specific issues in Template
+ management that may occur at IPFIX Mediators.
+
+4.1. Passing Unmodified Templates through an IPFIX Mediator
+
+ For some Intermediate Processes, the IPFIX Mediator doesn't modify
+ the (Options) Template Record(s) content. A typical example is an
+ Intermediate Flow Selection Process acting as distributor, which
+ collects Flow Records from one or more Exporters, and based on the
+ content of the Information Elements, redirects the Flow Records to
+ the appropriate Collector. This example is a typical case of a
+ single network operation center managing multiple universities: a
+ unique IPFIX Collector collects all Flow Records for the common
+ infrastructure, but might be re-exporting specific university Flow
+ Records to the responsible system administrator.
+
+ As specified in [RFC7011], the Template IDs are unique per Exporter,
+ per Transport Session, and per Observation Domain. As there is no
+ guarantee that, for similar Template Records, the Template IDs
+ received on the incoming Transport Session and exported to the
+ outgoing Transport Session would be same, the IPFIX Mediator MUST
+ maintain a Template Mapping composed of related received and exported
+ (Options) Template Records:
+
+ o for each received (Options) Template Record: Template Record
+ Information Elements, Template ID, Observation Domain ID, and
+ Transport Session information, metadata scoped to the Template (*)
+
+ o for each exported (Options) Template Record: Template Record
+ Information Elements, Template ID, Collector, Observation Domain
+ ID, and Transport Session information metadata scoped to the
+ Template (*)
+
+ (*) The "metadata scoped to the Template" encompasses the metadata,
+ that are scoped to the Template, and that help to determine the
+ semantics of the Template Record. Note that these metadata are
+ typically sent in Data Records described by an Options Template. An
+ example is the flowKeyIndicator. An IPFIX Mediator could potentially
+ receive two different Template IDs, from the same Exporter, with the
+ same Information Elements, but with a different set of Flow Keys
+ (indicated by the flowKeyIndicator in an Options Template Record).
+ Another example is the combination of anonymizationFlags and
+ anonymizationTechnique [RFC6235]). This metadata information must be
+ present in the Template Mapping, to stress that the two Template
+ Record semantics are different.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 11]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
+ (Options) Template Record that is not used anymore in any other
+ Template Mappings, the IPFIX Mediator SHOULD export the appropriate
+ IPFIX Withdrawal Message(s) on the outgoing Transport Session and
+ remove the corresponding entry in the Template Mapping.
+
+ If a (Options) Template Record is not used anymore in an outgoing
+ Transport Session, it MUST be withdrawn with an IPFIX Template
+ Withdrawal Message on that specific outgoing Transport Session, and
+ its entry, MUST be removed from the Template Mapping.
+
+ If an incoming or outgoing Transport Session is gracefully shut down
+ or reset, the (Options) Template Records corresponding to that
+ Transport Session MUST be removed from the Template Mapping.
+
+ For example, Figure 2 displays an example of an Intermediate Flow
+ Selection Process, redistributing Data Records to Collectors on the
+ basis of customer networks, i.e., the Route Distinguisher (RD). In
+ this example, the Template Record received from the Exporter #1 is
+ reused towards Collector #1, Collector #2, and Collector #3, for the
+ customer #1, customer #2, and customer #3, respectively. In this
+ example, the outgoing Template Records exported to the different
+ Collectors are identical. As a reminder that the Template ID
+ uniqueness is local to the Transport Session and Observation Domain
+ that generated the Template ID, a mix of Template ID 256 and 257 has
+ been used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 12]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ .---------.
+ Tmpl. | |
+ ID .---->|Collector|<==>Customer 1
+ 256 | | #1 |
+ | | |
+ RD=100:1 '---------'
+ .--------. .--------. |
+ | | Tmpl. | |----'
+ | | Id | | .---------.
+ | | 258 | | RD=100:2 | |
+ | IPFIX |------->| IPFIX |--------->|Collector|<==>Customer 2
+ |Exporter| |Mediator| Tmpl. | #2 |
+ | #1 | | | ID 257 | |
+ | | | | '---------'
+ | | | |----.
+ '--------' '--------' |
+ RD=100:3
+ | .---------.
+ Tmpl. | | |
+ ID '---->|Collector|<==>Customer 3
+ 257 | #3 |
+ | |
+ '---------'
+
+ Figure 2: Intermediate Flow Selection Process Example
+
+ Figure 3 shows the Template Mapping for the system shown in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 13]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ +-----------------------------------------------------------------+
+ | Template Entry A: |
+ | Incoming Transport Session information (from Exporter#1): |
+ | Source IP: <Exporter#1 export IP address> |
+ | Destination IP: <IPFIX Mediator IP address> |
+ | Protocol: SCTP |
+ | Source Port: <source port> |
+ | Destination Port: 4739 (IPFIX) |
+ | Observation Domain ID: <Observation Domain ID> |
+ | Template ID: 258 |
+ | Metadata scoped to the Template : <not applicable in this case> |
+ | |
+ | Template Entry B: |
+ | Outgoing Transport Session information (to Collector#1): |
+ | Source IP: <IPFIX Mediator IP address> |
+ | Destination IP: <IPFIX Collector#1 IP address> |
+ | Protocol: SCTP |
+ | Source Port: <source port> |
+ | Destination Port: 4739 (IPFIX) |
+ | Observation Domain ID: <Observation Domain ID> |
+ | Template ID: 256 |
+ | Metadata scoped to the Template : <not applicable in this case> |
+ | |
+ | Template Entry C: |
+ | Outgoing Transport Session information (to Collector#2): |
+ | Source IP: <IPFIX Mediator IP address> |
+ | Destination IP: <IPFIX Collector#2 IP address> |
+ | Protocol: SCTP |
+ | Source Port: <source port> |
+ | Destination Port: 4739 (IPFIX) |
+ | Observation Domain ID: <Observation Domain ID> |
+ | Template ID: 257 |
+ | Metadata scoped to the Template : <not applicable in this case> |
+ | |
+ | Template Entry D: |
+ | Outgoing Transport Session information (to Collector#3): |
+ | Source IP: <IPFIX Mediator IP address> |
+ | Destination IP: <IPFIX Collector#3 IP address> |
+ | Protocol: SCTP |
+ | Source Port: <source port> |
+ | Destination Port: 4739 (IPFIX) |
+ | Observation Domain ID: <Observation Domain ID> |
+ | Template ID: 257 |
+ | Metadata scoped to the Template : <not applicable in this case> |
+ +-----------------------------------------------------------------+
+
+ Figure 3: Template Mapping Example: Templates
+
+
+
+
+Claise, et al. Standards Track [Page 14]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ The Template Mapping corresponding to Figure 3 is displayed in
+ Figure 4:
+
+ Template Entry A <----> Template Entry B
+ Template Entry A <----> Template Entry C
+ Template Entry A <----> Template Entry D
+
+ Figure 4: Template Mapping Example: Mappings
+
+ Alternatively, the Template Mapping may be optimized as in Figure 5:
+
+ +--> Template Entry B
+ |
+ Template Entry A <--+--> Template Entry C
+ |
+ +--> Template Entry D
+
+ Figure 5: Template Mapping Example 2: Mappings
+
+ Note that all examples use Transport Sessions based on the SCTP, as
+ simplified use cases. However, the transport protocol would be
+ important in situations such as an Intermediate Conversion Process
+ doing transport protocol conversion.
+
+4.1.1. Template Mapping and Information Element Ordering
+
+ In the situation where Original Exporters each export an (Options)
+ Template Record to a single IPFIX Mediator, and the (Options)
+ Template Record contains the same Information Elements, but in
+ different order, should the IPFIX Mediator maintain a Template
+ Mapping with a single Export Template Record (see Figure 6) or should
+ the IPFIX Mediator maintain multiple independent Template Records
+ (see Figure 7) before re-exporting to the Collector?
+
+ Template Entry A <--+
+ |
+ Template Entry B <--+--> Template Entry D
+ |
+ Template Entry C <--+
+
+ Figure 6: Template Mapping and Ordering:
+ A single Export Template Record
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 15]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ Template Entry A <--+--> Template Entry D
+
+ Template Entry B <--+--> Template Entry E
+
+ Template Entry C <--+--> Template Entry F
+
+ Figure 7: Template Mapping and Ordering:
+ Multiple Export Template Records
+
+ The answer depends on whether the order of the Information Elements
+ implies some specific semantic. One of the guiding principles in
+ IPFIX protocol specifications is that the semantic meaning of one
+ Information Element doesn't depend on the value of any other
+ Information Element. However, there is one noticeable exception, as
+ mentioned in [RFC7011]:
+
+ Multiple Scope Fields MAY be present in the Options Template
+ Record, in which case the composite scope is the combination of
+ the scopes. For example, if the two scopes are meteringProcessId
+ and templateId, the combined scope is this Template for this
+ Metering Process. If a different order of Scope Fields would
+ result in a Record having a different semantic meaning, then the
+ order of Scope Fields MUST be preserved by the Exporting Process.
+ For example, in the context of PSAMP [RFC5476], if the first scope
+ defines the filtering function, while the second scope defines the
+ sampling function, the order of the scope is important. Applying
+ the sampling function first, followed by the filtering function,
+ would lead to potentially different Data Records than applying the
+ filtering function first, followed by the sampling function.
+
+ If an IPFIX Mediator receives, from multiple Exporters, Template
+ Records with identical Information Elements, but ordered differently,
+ it SHOULD consider those Template Records as identical, subject to
+ metadata information in the associated Options Template (for example,
+ the Flow Key Options Template, see Section 10.2).
+
+ If an IPFIX Mediator receives, from multiple Exporters, Options
+ Template Records with identical and ordered Information Elements in
+ the Scope fields, and with identical Information Elements, but
+ ordered differently, in the non-Scope fields, it SHOULD consider
+ those Template Records as identical.
+
+ If an IPFIX Mediator receives, from multiple Exporters, Options
+ Template Records with identical Information Elements in the Scope
+ field, but ones that are ordered differently, it MUST consider those
+ Template Records as semantically different.
+
+
+
+
+
+Claise, et al. Standards Track [Page 16]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+4.2. Creating New Templates at an IPFIX Mediator
+
+ For other Intermediate Processes, the IPFIX Mediator generates new
+ (Options) Template Records as a result of the Intermediate Process.
+
+ In these cases, the IPFIX Mediator doesn't need to maintain a
+ Template Mapping, as it generates its own series of (Options)
+ Template Records. However, some special cases might still require a
+ Template Mapping. Consider a situation where the IPFIX Mediator
+ generates new (Options) Template Records based on what it receives
+ from the Exporter(s) based on the Intermediate Process function: for
+ example, an Intermediate Anonymization process that performs black-
+ marker anonymization [RFC6235] on certain Information Elements. In
+ such cases, it's important to keep the correlation between the
+ received (Options) Template Records and derived (Options) Template
+ Records in the Template Mapping. These Template Mappings would be
+ kept as in Section 4.1, except that the exported Template would not
+ be identical to the received Template.
+
+ Similar to Exporting Processes in any Exporter, an IPFIX Mediator may
+ use the technique for reducing redundancy in IPFIX described in
+ [RFC5473].
+
+4.3. Handling Unknown Information Elements
+
+ Depending on application requirements, Mediators that do not generate
+ new Records SHOULD re-export values for unknown Information Elements,
+ for which the Mediator does not have information about Information
+ Element data type and semantics. However, as there may be presence
+ or ordering dependencies among the unknown Information Elements, the
+ Mediator MUST NOT omit fields from such re-exported Records or
+ reorder any fields within the Records.
+
+ Mediators that generate new Records, as in Section 4.2, MUST ignore
+ values of Information Elements they do not understand. If a Mediator
+ passes values of Information Elements it does not understand (for
+ example, when re-exporting Flow Records), it MUST pass them in the
+ order in which they were originally received.
+
+ In any case, Mediators handling unknown Information Elements SHOULD
+ log this fact, as it is likely that mediation of records containing
+ unknown values will have unintended consequences.
+
+5. Preserving Original Observation Point Information
+
+ Depending on the use case, the Collector in an Exporter/IPFIX
+ Mediator/Collector structure (for example, tiered Mediators) may need
+ to receive information about the Original Observation Point(s);
+
+
+
+Claise, et al. Standards Track [Page 17]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ otherwise, it may wrongly conclude that the IPFIX Device exporting
+ the Flow Records, i.e., the IPFIX Mediator, directly observed the
+ packets that generated the Flow Records. Two new Information
+ Elements are introduced to address this use case:
+ originalExporterIPv4Address and originalExporterIPv6Address.
+ Practically, the Original Exporters will not be exporting these
+ Information Elements. Therefore, the Intermediate Process will
+ report the Original Observation Point(s) to the best of its
+ knowledge. Note that the Configuration Data Model for IPFIX and
+ PSAMP [RFC6728] may report the Original Exporter information out of
+ band.
+
+ In the IPFIX Mediator, the Observation Point(s) may be represented
+ by:
+
+ o A single Original Exporter (represented by the
+ originalExporterIPv4Address or originalExporterIPv6Address
+ Information Elements).
+
+ o A list of Original Exporters (represented by a list of
+ originalExporterIPv4Address or originalExporterIPv6Address
+ Information Elements).
+
+ o Any combination or list of Information Elements representing
+ Observation Points. For example:
+
+ * A list of Original Exporter interfaces (represented by the
+ originalExporterIPv4Address or originalExporterIPv6Address, the
+ ingressInterface, and/or egressInterface Information Elements,
+ respectively).
+
+ * A list of Original Exporter line card (represented by the
+ originalExporterIPv4Address, originalExporterIPv6Address, or
+ lineCardId Information Elements, respectively).
+
+ Some Information Elements characterizing the Observation Point may be
+ added. For example, the flowDirection Information Element specifies
+ the direction of the observation, and, as such, characterizes the
+ Observation Point.
+
+ Any combination of the above representations is possible. An example
+ of an Original Observation Point for an Intermediate Aggregation
+ Process is displayed in Figure 8.
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 18]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ exporterIPv4Address 192.0.2.1
+ exporterIPv4Address 192.0.2.2,
+ interface ethernet 0, direction ingress
+ interface ethernet 1, direction ingress
+ interface serial 1, direction egress
+ interface serial 2, direction egress
+ exporterIPv4Address 192.0.2.3,
+ lineCardId 1, direction ingress
+
+ Figure 8: Complex Observation Point Definition Example
+
+ A Mediator MAY export such complex Original Observation Point
+ information, depending on application requirements. If such
+ information is exported, the Mediator MUST use [RFC6313] to do so, as
+ described below.
+
+ The most generic way to export the Original Observation Point is to
+ use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking
+ the previous example, the encoding in Figure 9 can be used.
+
+ Template Record 257: exporterIPv4Address
+ Template Record 258: exporterIPv4Address,
+ basicList of ingressInterface, flowDirection
+ Template Record 259: exporterIPv4Address, lineCardId, flowDirection
+
+ Figure 9: Complex Observation Point Definition Example: Templates
+
+ The Original Observation Point is modeled with the Data Records
+ corresponding to either Template Record 1, Template Record 2, or
+ Template Record 3 but not more than one of these ("exactlyOneOf"
+ semantic). This implies that the Flow was observed at exactly one of
+ the Observation Points reported.
+
+ When an IPFIX Mediator receives Flow Records containing the Original
+ Observation Point Information Element, i.e.,
+ originalExporterIPv4Address or originalExporterIPv6Address, the IPFIX
+ Mediator SHOULD NOT modify its value(s) when composing new Flow
+ Records in the general case. Known exceptions include anonymization
+ per Section 7.2.4 of [RFC6235] and an Intermediate Correlation
+ Process rewriting addresses across NAT. In other words, the Original
+ Observation Point should not be replaced with the IPFIX Mediator
+ Observation Point. The daisy chain of (Exporter, Observation Point)
+ representing the path the Flow Records took from the Exporter to the
+ top Collector in the Exporter/IPFIX Mediator(s)/Collector structure
+ model is out of the scope of this specification.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 19]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ The following subsections describe Information Elements for reporting
+ Original Exporter addresses as seen by the Collecting Process; note
+ they may be subject to network address translation upstream; see
+ [NAT-LOGGING] for more on logging in this situation.
+
+5.1. originalExporterIPv4Address Information Element
+
+ Name: originalExporterIPv4Address
+
+ Description: The IPv4 address used by the Exporting Process on an
+ Original Exporter, as seen by the Collecting Process on an IPFIX
+ Mediator. Used to provide information about the Original
+ Observation Points to a downstream Collector.
+
+ Data Type: ipv4Address
+
+ ElementId: 403
+
+5.2. originalExporterIPv6Address Information Element
+
+ Name: originalExporterIPv6Address
+
+ Description: The IPv6 address used by the Exporting Process on an
+ Original Exporter, as seen by the Collecting Process on an IPFIX
+ Mediator. Used to provide information about the Original
+ Observation Points to a downstream Collector.
+
+ Data Type: ipv6Address
+
+ ElementId: 404
+
+6. Managing Observation Domain IDs
+
+ The Observation Domain ID of any IPFIX Message containing Flow
+ Records relevant to no particular Observation Domain, or to multiple
+ Observation Domains, MUST have an Observation Domain ID of 0.
+
+ IPFIX Mediators that do not change (Options) Template Records MUST
+ maintain a Template Mapping, as detailed in Section 4.1, to ensure
+ that the combination of Observation Domain IDs and Template IDs do
+ not collide on export.
+
+ For IPFIX Mediators that export New (Options) Template Records, as in
+ Section 4.2, there are two options for Observation Domain ID
+ management. The first and simplest of these is to completely
+ decouple exported Observation Domain IDs from received Observation
+
+
+
+
+
+Claise, et al. Standards Track [Page 20]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ Domain IDs; the IPFIX Mediator, in this case, comprises its own set
+ of Observation Domain(s) independent of the Observation Domain(s) of
+ the Original Exporters.
+
+ The second option is to provide or maintain a Template Mapping for
+ received (Options) Template Records and exported inferred (Options)
+ Template Records, along with the appropriate Observation Domain IDs
+ per Transport Session, which ensures that the combination of
+ Observation Domain IDs and Template IDs do not collide on export.
+
+ In some cases where the IPFIX Message Header can't contain a
+ consistent Observation Domain for the entire IPFIX Message, but the
+ Flow Records exported from the IPFIX Mediator should contain the
+ Observation Domain of the Original Exporter anyway, the (Options)
+ Template Record must contain the originalObservationDomainId
+ Information Element, specified in Section 6.1. When an IPFIX
+ Mediator receives Flow Records containing the
+ originalObservationDomainId Information Element, the IPFIX Mediator
+ MUST NOT modify its value(s) when composing new Flow Records with the
+ originalObservationDomainId Information Element.
+
+6.1. originalObservationDomainId Information Element
+
+ Name: originalObservationDomainId
+
+ Description: The Observation Domain ID reported by the Exporting
+ Process on an Original Exporter, as seen by the Collecting Process
+ on an IPFIX Mediator. Used to provide information about the
+ Original Observation Domain to a downstream Collector. When
+ cascading through multiple Mediators, this identifies the initial
+ Observation Domain in the cascade.
+
+ Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ ElementId: 405
+
+7. Timing Considerations
+
+ The IPFIX Message Header "Export Time" field is the time in seconds
+ since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the
+ IPFIX Mediator. However, in the specific case of an IPFIX Mediator
+ containing an Intermediate Conversion Process, the IPFIX Mediator MAY
+ use the export time received from the incoming Transport Session.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 21]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ It is RECOMMENDED that IPFIX Mediators handle time using absolute
+ timestamps (e.g., flowStartSeconds, flowStartMilliseconds, or
+ flowStartNanoseconds), which are specified relative to the UNIX epoch
+ (00:00 UTC 1 Jan 1970) [POSIX.1], where possible rather than relative
+ timestamps (e.g., flowStartSysUpTime or flowStartDeltaMicroseconds),
+ which are specified relative to protocol structures such as system
+ initialization or message export time.
+
+ The latter are difficult to manage for two reasons. First, they
+ require constant translation, as the system initialization time of an
+ intermediate system and the export time of an intermediate message
+ will change across mediation operations. Further, relative
+ timestamps introduce range problems. For example, when using the
+ flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information
+ Elements [IANA-IPFIX], the Data Record must be exported within a
+ maximum of 71 minutes after its creation. Otherwise, the 32-bit
+ counter would not be sufficient to contain the flow start time
+ offset. Those time constraints might be incompatible with some of
+ the application requirements of some Intermediate Processes.
+
+ Intermediate Processes MUST NOT assume that received records appear
+ in flowStartTime, flowEndTime, or observationTime order. An
+ Intermediate Process processing timing information (e.g., an
+ Intermediate Aggregation Process) MAY ignore records that are
+ significantly out of order, in order to meet application-specific
+ state and latency requirements, but SHOULD report that records were
+ dropped.
+
+ When an Intermediate Process aggregates information from different
+ Flow Records, the timestamps on exported records SHOULD be the
+ minimum of the start times and the maximum of the end times in the
+ general case. However, if the Flow Records do not overlap, i.e., if
+ there is a time gap between the times in the Flow Records, then the
+ report may be inaccurate. The IPFIX Mediator is only reporting what
+ it knows, on the basis of the information made available to it, and
+ there may not have been any data to observe during the gap. Then
+ again, if there is an overlap in timestamps, there's the potential of
+ double-accounting: different Observation Points may have observed the
+ same traffic simultaneously. The specification of the precise rules
+ for applying Flow Record timestamps at IPFIX Mediators for all the
+ different situations is out of the scope of this document.
+
+ Note that [RFC7015] provides additional specifications for handling
+ of timestamps at an Intermediate Aggregation Process.
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 22]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+8. Transport Considerations
+
+ SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension
+ specified in [RFC3758] MUST be implemented by all compliant IPFIX
+ Mediator implementations. TCP [RFC0793] MAY also be implemented by
+ implementations compliant with the IPFIX Mediator. UDP [RFC0768] MAY
+ also be implemented by compliant IPFIX Mediator implementations.
+ Transport-specific considerations for IPFIX Exporters as specified in
+ Sections 8.3, 8.4, 9.1, 9.2, and 10 of [RFC7011] apply to IPFIX
+ Mediators as well.
+
+ SCTP SHOULD be used in deployments where IPFIX Mediators and
+ Collectors are communicating over links that are susceptible to
+ congestion. SCTP is capable of providing any required degree of
+ reliability. TCP MAY be used in deployments where IPFIX Mediators
+ and Collectors communicate over links that are susceptible to
+ congestion, but SCTP is preferred due to its ability to limit back
+ pressure on Exporters and its message versus stream orientation. UDP
+ MAY be used, although it is not a congestion-aware protocol.
+ However, in this case, the IPFIX traffic between IPFIX Mediator and
+ Collector MUST run in an environment where IPFIX traffic has been
+ provisioned for and/or separated from non-IPFIX traffic, whether
+ physically or virtually.
+
+9. Collecting Process Considerations
+
+ Any Collecting Process compliant with [RFC7011] can receive IPFIX
+ Messages from an IPFIX Mediator. If the IPFIX Mediator uses IPFIX
+ Structured Data [RFC6313] to export Original Exporter Information, as
+ in Section 5, the Collecting Process MUST support [RFC6313].
+
+10. Specific Reporting Requirements
+
+ IPFIX provides Options Templates for the reporting the reliability of
+ processes within the IPFIX Architecture. As each Mediator includes
+ at least one IPFIX Exporting Process, they MAY use the Exporting
+ Process Reliability Statistics Options Template, as specified in
+ [RFC7011].
+
+ Analogous to the Metering Process Reliability Statistics Options
+ Template, also specified in [RFC7011], Mediators MAY implement the
+ Intermediate Process Reliability Statistics Options Template,
+ specified in Sections 10.1, 10.3, and 10.4 define Information
+ Elements used by this Options Template.
+
+ The Flow Keys Options Template, as specified in [RFC7011], may
+ require special handling at an IPFIX Mediator, as described in
+ Section 10.2.
+
+
+
+Claise, et al. Standards Track [Page 23]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ In addition, each Intermediate Process may have its own specific
+ reporting requirements (e.g., Anonymization Records as in [RFC6235],
+ or the Aggregation Counter Distribution Options Template as in
+ [RFC7015]); these SHOULD be implemented as necessary, as described in
+ the specification for each Intermediate Process.
+
+10.1. Intermediate Process Reliability Statistics Options Template
+
+ The Intermediate Process Statistics Options Template specifies the
+ structure of a Data Record for reporting Intermediate Process
+ statistics. It SHOULD contain the following Information Elements;
+ the intermediateProcessId Information Element is defined in
+ Section 10.3 and the ignoredDataRecordTotalCount Information Element
+ is defined in Section 10.4:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 24]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ +-----------------------------+-------------------------------------+
+ | IE | Description |
+ +-----------------------------+-------------------------------------+
+ | observationDomainId [scope] | An identifier of the Observation |
+ | | Domain (of messages exported by |
+ | | this Mediator), locally unique to |
+ | | the Intermediate Process, to which |
+ | | this statistics record applies. |
+ | | ---------------------------------- |
+ | intermediateProcessId | An identifier for the Intermediate |
+ | [scope] | Process to which this statistics |
+ | | record applies. |
+ | | ---------------------------------- |
+ | ignoredDataRecordTotalCount | The total number of Data Records |
+ | | received but not processed by the |
+ | | Intermediate Process. |
+ | | ---------------------------------- |
+ | time first record ignored | The timestamp of the first record |
+ | | that was ignored by the |
+ | | Intermediate Process. For Data |
+ | | Records containing timestamp |
+ | | ranges, this SHOULD be taken from |
+ | | the start timestamp of the range; |
+ | | for data records containing no |
+ | | timing information, this SHOULD be |
+ | | taken from the Export Time in the |
+ | | message header of the IPFIX Message |
+ | | that contains it. For this |
+ | | timestamp, any of the following |
+ | | timestamp can be used: |
+ | | observationTimeSeconds, |
+ | | observationTimeMilliseconds, |
+ | | observationTimeMicroseconds, or |
+ | | observationTimeNanoseconds. |
+ +-----------------------------+-------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 25]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ +-----------------------------+-------------------------------------+
+ | IE | Description |
+ +-----------------------------+-------------------------------------+
+ | time last record ignored | The timestamp of the last record |
+ | | that was ignored by the |
+ | | Intermediate Process. For Data |
+ | | Records containing timestamp |
+ | | ranges, this SHOULD be taken from |
+ | | the end timestamp of the range; for |
+ | | data records containing no timing |
+ | | information, this SHOULD be taken |
+ | | from the Export Time in the message |
+ | | header of the containing IPFIX |
+ | | Message. For this timestamp, any |
+ | | of the following timestamp can be |
+ | | used: observationTimeSeconds, |
+ | | observationTimeMilliseconds, |
+ | | observationTimeMicroseconds, or |
+ | | observationTimeNanoseconds. |
+ +-----------------------------+-------------------------------------+
+
+10.2. Flow Key Options Template
+
+ The Flow Keys Options Template specifies the structure of a Data
+ Record for reporting the Flow Keys of reported Flows. A Flow Keys
+ Data Record extends a particular Template Record that is referenced
+ by its templateId identifier. The Template Record is extended by
+ specifying which of the Information Elements contained in the
+ corresponding Data Records describe Flow properties that serve as
+ Flow Keys of the reported Flow. This Options Template is defined in
+ Section 4.4 of [RFC7011] and SHOULD be used by Mediators for export
+ as defined there.
+
+ When an Intermediate Process exports Data Records containing
+ different Flow Keys from those received from the Original Exporter,
+ and the Original Exporter sent a Flow Keys Options record to the
+ IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options
+ record defining the new set of Flow Keys.
+
+10.3. intermediateProcessId Information Element
+
+ Name: intermediateProcessId
+
+ Description: An identifier of an Intermediate Process that is
+ unique per IPFIX Device. Typically, this Information Element is
+ used for limiting the scope of other Information Elements. Note
+ that process identifiers may be assigned dynamically; that is, an
+ Intermediate Process may be restarted with a different ID.
+
+
+
+Claise, et al. Standards Track [Page 26]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ Data Type: unsigned32
+
+ Data Type Semantics: identifier
+
+ ElementId: 406
+
+10.4. ignoredDataRecordTotalCount Information Element
+
+ Name: ignoredDataRecordTotalCount
+
+ Description: The total number of received Data Records that the
+ Intermediate Process did not process since the (re-)initialization
+ of the Intermediate Process; includes only Data Records not
+ examined or otherwise handled by the Intermediate Process due to
+ resource constraints, not Data Records that were examined or
+ otherwise handled by the Intermediate Process but those that
+ merely do not contribute to any exported Data Record due to the
+ operations performed by the Intermediate Process.
+
+ Data Type: unsigned64
+
+ Data Type Semantics: totalCounter
+
+ ElementId: 407
+
+11. Operations and Management Considerations
+
+ In general, using IPFIX Mediators to combine information from
+ multiple Original Exporters requires a consistent configuration of
+ the Metering Processes behind these Original Exporters. The details
+ of this consistency are specific to each Intermediate Process.
+ Consistency of configuration should be verified out of band, with the
+ MIB modules ([RFC6615] and [RFC6727]) or with the Configuration Data
+ Model for IPFIX and PSAMP [RFC6728].
+
+ From an operational perspective, this specification provides all the
+ information required to set up IPFIX Mediators and Collectors behind
+ IPFIX Mediators. While configuring the IPFIX Mediators, care must be
+ taken to include all the relevant information so that the Collectors
+ deduce the Data Records precise semantic. This is covered by the
+ Template Mapping specifications in Section 4.1. Also, caution must
+ be taken that if something is not carefully configured in the
+ processing chain, this can lead to the wrong interpretation of
+ collected IPFIX data, and the associated applications can produce
+ results that are not operationally meaningful.
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 27]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+12. Security Considerations
+
+ As they act as both IPFIX Collecting Processes and Exporting
+ Processes, the Security Considerations for the IPFIX Protocol
+ [RFC7011] also apply to IPFIX Mediators. The Security Considerations
+ for IPFIX Files [RFC5655] also apply to IPFIX Mediators that write
+ IPFIX Files or use them for internal storage. However, there are a
+ few specific considerations that IPFIX Mediator implementations must
+ also take into account.
+
+ By design, IPFIX Mediators are "men in the middle": they intercede in
+ the communication between an Original Exporter (or another upstream
+ IPFIX Mediator) and a downstream Collecting Process. This has two
+ important implications for the level of confidentiality provided
+ across an IPFIX Mediator and the ability to protect data integrity
+ and Original Exporter authenticity across an IPFIX Mediator. These
+ are addressed in more detail in the Security Considerations for IPFIX
+ Mediators in [RFC6183].
+
+ Note that while IPFIX Mediators can use the exporterCertificate and
+ collectorCertificate Information Elements defined in [RFC5655] as
+ described in Section 9.3 of [RFC6183] to export information about
+ X.509 identities in upstream TLS-protected Transport Sessions, this
+ mechanism cannot be used to provide true end-to-end assertions about
+ a chain of IPFIX Mediators: any IPFIX Mediator in the chain can
+ simply falsify the information about upstream Transport Sessions. In
+ situations where information about the chain of mediation is
+ important, it must be determined out of band. Note as well that an
+ Exporting Process has no in-band way to determine whether or not a
+ given Collecting Process will act as a Mediator. Trust placed in
+ Collecting Processes is absolute, so care should be taken when
+ exporting IPFIX Messages between Exporting Processes and Collecting
+ Processes controlled by different entities.
+
+13. IANA Considerations
+
+ This document specifies new IPFIX Information Elements,
+ originalExporterIPv4Address in Section 5.1,
+ originalExporterIPv6Address in Section 5.2,
+ originalObservationDomainId in Section 6.1, intermediateProcessId in
+ Section 10.3, and ignoredDataRecordTotalCount in Section 10.4, which
+ have been added to the IPFIX Information Element registry
+ [IANA-IPFIX].
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 28]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+14. Acknowledgments
+
+ We would like to thank the IPFIX contributors, specifically Paul
+ Aitken (THE ultimate IPFIX document reviewer) and Andrew Feren for
+ their thorough reviews; Nevil Brownlee and Juergen Quittek for
+ shepherding this document and chairing the IPFIX Working Group; and
+ to Rahul Patel, Meral Shirazipour, and Juergen Schoenwaelder for
+ their feedback and comments. This work is materially supported by
+ the European Union Seventh Framework Programme under grant agreements
+ 257315 (DEMONS) and 318627 (mPlane).
+
+15. References
+
+15.1. Normative References
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+ Conrad, "Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension", RFC 3758, May 2004.
+
+ [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
+ 4960, September 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
+ Wagner, "Specification of the IP Flow Information Export
+ (IPFIX) File Format", RFC 5655, October 2009.
+
+ [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+ "Export of Structured Data in IP Flow Information Export
+ (IPFIX)", RFC 6313, July 2011.
+
+ [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
+ "Definitions of Managed Objects for IP Flow Information
+ Export", RFC 6615, June 2012.
+
+
+
+
+
+Claise, et al. Standards Track [Page 29]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ [RFC6727] Dietz, T., Claise, B., and J. Quittek, "Definitions of
+ Managed Objects for Packet Sampling", RFC 6727, October
+ 2012.
+
+ [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data
+ Model for the IP Flow Information Export (IPFIX) and
+ Packet Sampling (PSAMP) Protocols", RFC 6728, October
+ 2012.
+
+ [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
+ the IP Flow Information Export (IPFIX) Protocol for the
+ Exchange of Flow Information", STD 77, RFC 7011, September
+ 2013.
+
+ [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
+ Information Export (IPFIX)", RFC 7012, September 2013.
+
+ [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
+ Reviewers of IP Flow Information Export (IPFIX)
+ Information Elements", BCP 184, RFC 7013, September 2013.
+
+ [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
+ Selection Techniques", RFC 7014, September 2013.
+
+ [RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
+ for the IP Flow Information Export (IPFIX) Protocol", RFC
+ 7015, September 2013.
+
+15.2. Informative References
+
+ [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
+ "Requirements for IP Flow Information Export (IPFIX)", RFC
+ 3917, October 2004.
+
+ [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version
+ 9", RFC 3954, October 2004.
+
+ [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
+ "Architecture for IP Flow Information Export", RFC 5470,
+ March 2009.
+
+ [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
+ Flow Information Export (IPFIX) Applicability", RFC 5472,
+ March 2009.
+
+ [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
+ in IP Flow Information Export (IPFIX) and Packet Sampling
+ (PSAMP) Reports", RFC 5473, March 2009.
+
+
+
+Claise, et al. Standards Track [Page 30]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+ [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
+ (PSAMP) Protocol Specifications", RFC 5476, March 2009.
+
+ [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby,
+ "Exporting Type Information for IP Flow Information Export
+ (IPFIX) Information Elements", RFC 5610, July 2009.
+
+ [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export
+ (IPFIX) Mediation: Problem Statement", RFC 5982, August
+ 2010.
+
+ [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
+ "IP Flow Information Export (IPFIX) Mediation: Framework",
+ RFC 6183, April 2011.
+
+ [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
+ Support", RFC 6235, May 2011.
+
+ [NAT-LOGGING]
+ Sivakumar, S. and R. Penno, "IPFIX Information Elements
+ for logging NAT Events", Work in Progress, November 2013.
+
+ [IANA-IPFIX]
+ IANA, "IP Flow Information Export (IPFIX) Entities",
+ <http://www.iana.org/assignments/ipfix>.
+
+ [POSIX.1] IEEE, "IEEE Standard for Information Technology - Portable
+ Operating System Interface", IEEE 1003.1-2008, 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 31]
+
+RFC 7119 IPFIX MED-PROTO February 2014
+
+
+Authors' Addresses
+
+ Benoit Claise
+ Cisco Systems, Inc.
+ De Kleetlaan 6a b1
+ 1831 Diegem
+ Belgium
+
+ Phone: +32 2 704 5622
+ EMail: bclaise@cisco.com
+
+
+ Atsushi Kobayashi
+ NTT Information Sharing Platform Laboratories
+ 3-9-11 Midori-cho
+ Musashino-shi, Tokyo 180-8585
+ Japan
+
+ Phone: +81 422 59 3978
+ EMail: akoba@nttv6.net
+
+
+ Brian Trammell
+ Swiss Federal Institute of Technology Zurich
+ Gloriastrasse 35
+ 8092 Zurich
+ Switzerland
+
+ Phone: +41 44 632 70 13
+ EMail: trammell@tik.ee.ethz.ch
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al. Standards Track [Page 32]
+