doc: Add RFC documents

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]
+