GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7119

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7119.txt · Last modified: 2014/02/13 04:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki