One document matched: draft-ietf-ipfix-mediation-protocol-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-ipfix-mediation-protocol-03.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IPFIX MED-PROTO">
Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
</title>
<author initials="B." surname="Claise" fullname="Benoit Claise">
<organization abbrev="Cisco Systems, Inc.">
Cisco Systems, Inc.
</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>1831 Diegem</city>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author>
<author initials="A." surname="Kobayashi" fullname="Atsushi Kobayashi">
<organization abbrev="NTT">
NTT Information Sharing Platform Laboratories
</organization>
<address>
<postal>
<street>3-9-11 Midori-cho</street>
<city>Musashino-shi, Tokyo 180-8585</city>
<country>Japan</country>
</postal>
<phone>+81 422 59 3978</phone>
<email>akoba@nttv6.net</email>
</address>
</author>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 632 70 13</phone>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<date month="January" day="4" year="2013"/>
<area>Operations</area>
<workgroup>IPFIX Working Group</workgroup>
<abstract>
<t>This document specifies the 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The IPFIX architectural components in <xref target="RFC5470"/> consist of
IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol
<xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, 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.).</t>
<t>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 <xref
target="I-D.ietf-ipfix-information-model-rfc5102bis"/>, registered with
IANA, or specified as an enterprise-specific Information Element. The
specifications in the IPFIX protocol <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> have not been defined in the
context of an IPFIX Mediator receiving, aggregating, correlating,
anonymizing, etc... Flow Records from the one or multiple Exporters. Indeed,
the IPFIX protocol must be adapted for Intermediate Processes, as defined in
the IPFIX Mediation Reference Model as specified in Figure A of <xref
target="RFC6183"/>, which is based on the IPFIX Mediation Problem Statement
<xref target="RFC5982"/>.</t>
<t>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 a Mediator -- a device which contains both
as 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 <xref target="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 considerations for aggregation.</t>
<t>The specifications in this document are based on the IPFIX protocol
specifications <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/> but
adapted according to the IPFIX Mediation Framework <xref
target="RFC6183"/>.</t>
<section title="IPFIX Documents Overview">
<!-- copy over from aggregation? -->
<t>The IPFIX Protocol <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>
provides network administrators with access to IP Flow information.</t>
<t>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 <xref target="RFC5470"/>, per the requirements defined in the
IPFIX Requirement doc, <xref target="RFC3917"/>.</t>
<t>The IPFIX Architecture <xref target="RFC5470"/> specifies how IPFIX
Data Records and Templates are carried via a congestion-aware transport
protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.</t>
<t>IPFIX has a formal description of IPFIX Information Elements, their
name, type and additional semantic information, as specified in the IPFIX
Information Model <xref
target="I-D.ietf-ipfix-information-model-rfc5102bis"/>.</t>
<t>The IPFIX Applicability Statement <xref target="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.</t>
<t>"IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>,
describing the IPFIX Mediation applicability examples, along with some
problems that network administrators have been facing, is the basis for
the "IPFIX Mediation: Framework" <xref target="RFC6183"/>. This framework
details the IPFIX Mediation reference model and the components of an IPFIX
Mediator.</t>
</section>
<section title="IPFIX Mediator Documents Overview">
<t>The "IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>
provides an overview of the applicability of Mediators, and defines
requirements for 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 Mediators within an
IPFIX collection infrastructure.</t>
<t>The "IPFIX Mediation: Framework" <xref target="RFC6183"/> provides more
architectural details of the arrangement of Intermediate Processes within
a Mediator.</t>
<t>The details of specific Intermediate Processes, when these have
additional export specifications (e.g., metadata about the intermediate
processing conveyed through IPFIX Options Templates), are each treated in
their own document (e.g., the "IP Flow Anonymization Support" <xref
target="RFC6235"/>). Documents specifying the operations of specific
Intermediate Processes cover the operation of these Processes within the
Mediator framework, and comply with the specifications given in this
document; they may additionally specify the operation of the process
independently, outside the context of a Mediator, when this is
appropriate. As of today, these documents are:</t>
<list style="numbers">
<t>"IP Flow Anonymization Support", <xref target="RFC6235"/>, which describes
Anonymization techniques for IP flow data and the export of Anonymized
data using the IPFIX protocol.</t>
<t>"Flow Selection Techniques" <xref
target="I-D.ietf-ipfix-flow-selection-tech"/>, 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.</t>
<t>"Exporting Aggregated Flow Data using IP Flow Information Export"
<xref target="I-D.ietf-ipfix-a9n"/> which describes Aggregated Flow
export within the framework of IPFIX Mediators and defines an
interoperable, implementation-independent method for Aggregated Flow
export.</t>
</list>
<t>This document specifies the IP Flow Information Export (IPFIX) protocol
specific to Mediation, i.e. the specifications that all Intermediate
Processes type must comply to. Some extra specifications might be required
per Intermediate Process type (In which case, the Intermediate Process
specific document would cover those).</t>
</section>
<section title="Relationship with IPFIX and PSAMP">
<t>The specification in this document applies to the IPFIX protocol
specifications <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. All
specifications from <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>
apply unless specified otherwise in this document.</t>
<t>As the Packet Sampling (PSAMP) protocol specifications <xref target="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.</t>
</section>
</section>
<section title="Terminology">
<t>[EDITOR'S NOTE: change to only define terms in this section that are
actually used in the document.]</t>
<t>[EDITOR'S NOTE: Definition change proposal for the Intermediate Process,
Intermediate Conversion Process, Intermediate Selection Process,
Intermediate Anonymization Process, and IPFIX Mediator. See
http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html. However,
the definitions are copied over verbatim from RFC6183. Also note that
Intermediate Anonymization Process in this document is not in line with the
RFC6235.]</t>
<t>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, and Transport Session, used in this document are defined in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. The PSAMP-specific terms used
in this document, such as Filtering and Sampling, are defined in <xref
target="RFC5476"/>.</t>
<t>IPFIX Mediation terms related to aggregation, such as the Interval,
Aggregated Flow, and Aggregated Function are defined in <xref
target="I-D.ietf-ipfix-a9n"/>.</t>
<t>The IPFIX Mediation-specific terminology used in this document is defined
in "IPFIX Mediation: Problem Statement" <xref target="RFC5982"/>, and reused
in "IPFIX Mediation: Framework" <xref target="RFC6183"/>. However, since
both of those documents are an informational RFCs, the definitions have been
reproduced here along with additional definitions.</t>
<t>Similarly, since <xref target="RFC6235"/> is an experimental RFC, the
Anonymization Record, Anonymized Data Record, and Intermediate Anonymization
Process terms, specified in <xref target="RFC6235"/>, are also reproduced
here.</t>
<t>In this document, as in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, <xref target="RFC5476"/>,
<xref target="I-D.ietf-ipfix-a9n"/>, and <xref target="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 of any
other format.</t>
<list style="hanging">
<t hangText="Transport Session Information: ">The Transport Session is
specified in <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>. In 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}.</t>
<t hangText="Original Exporter: ">An Original Exporter is an IPFIX Device
that hosts the Observation Points where the metered IP packets are
observed.</t>
<t hangText="Original Observation Point: ">An Observation Point of 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.</t>
<t hangText="IPFIX Mediation: ">IPFIX Mediation is the manipulation and
conversion of a record stream for subsequent export using the IPFIX
protocol.</t>
<t hangText="Template Mapping: ">A mapping from Template Records and/or
Options Template Records received by a 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.</t>
<t hangText="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 <xref target="RFC6235"/>.</t>
<t hangText="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
<xref target="RFC6235"/>.</t>
</list>
<t>The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation.</t>
<list style="hanging">
<t hangText="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.</t>
<t hangText="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 <xref target="RFC3954"/> to
IPFIX protocol.</t>
</list>
<t>Specific Intermediate Processes are described below. However, this is not an exhaustive list.</t>
<list style="hanging">
<t hangText="Intermediate Conversion Process: ">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 (or equivalent for non IPFIX protocols) in the case of
transport protocol conversion (e.g., from UDP to SCTP).</t>
<t hangText="Intermediate Aggregation Process: ">An Intermediate
Aggregation Process is an Intermediate Process that aggregates records
based upon a set of Flow Keys or functions applied to fields from the
record (e.g., binning and subnet aggregation).</t>
<t hangText="Intermediate Correlation Process: ">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).</t>
<t hangText="Intermediate Selection Process: ">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).</t>
<t hangText="Intermediate Anonymization Process: ">An Intermediate
Anonymization Process is an Intermediate Process that transforms records
in order to anonymize them, to protect the identity of the entities
described by the records (e.g., by applying prefix-preserving
pseudonymization of IP addresses).</t>
</list>
</section>
<section title="Handling IPFIX Message Headers" anchor="sec-header">
<t>The format of the IPFIX Message Header as exported by an IPFIX Mediator
is shown in <xref target="fig-header"/>. Note that the format is compatible
with the IPFIX Message Header defined in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, with some field definitions
(for the example, the Export Time) updated in the context of the IPFIX
Mediator.</t>
<figure title="IP Message Header format" anchor="fig-header">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The header fields as exported by an IPFIX Mediator are describe below.</t>
<list style="hanging">
<t hangText="Version: ">Version of Flow Record format exported in this
message. The value of this field is 0x000a for the current version,
incrementing by one the version used in the NetFlow services export
version 9 <xref target="RFC3954"/>.</t>
<t hangText="Length: ">Total length of the IPFIX Message, measured in
octets, including Message Header and Set(s).</t>
<t hangText="Export Time: ">Time at which the IPFIX Message leaves the
Mediator, expressed in seconds since the UNIX epoch of 1 January 1970 at
00:00 UTC, as defined in <xref target="POSIX.1"/> 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
keep the export time received from the incoming Transport Session.</t>
<t hangText="Sequence Number: "> Incremental sequence counter modulo 2^32
of all IPFIX Data Records sent in a 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
SHOULD 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. </t>
<t hangText="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 should be unique per IPFIX Device.
Collecting Processes SHOULD use the Transport Session and the Observation
Domain ID field to separate different export streams originating from the
same Exporting Process. The Observation Domain ID SHOULD be 0 when no
specific Observation Domain ID is relevant for the entire IPFIX Message.
For example, when exporting the Exporting Process Statistics, or in case
of hierarchy of Collector when aggregated Data Records are exported. See
<xref target="sec-tmpl-passthrough"/> for special considerations for
Observation Domain management while passing unmodified templates through a
Mediator, and <xref target="sec-oop"/> for guidelines for preservation of
original Observation Domain information at a Mediator.</t>
</list>
</section>
<section title="Template Management">
<t>How a Mediator handles the Templates it receives from the Original
Exporter depends entirely on the nature of the Intermediate Process running
on that Mediator. For Mediators which pass substantially the same Data
Records from the Original Exporter downstream, (e.g., an Intermediate
Selection Process), the templates can be passed unmodified as described in
<xref target="sec-tmpl-passthrough"/>; this section describes a Template
Mapping required to make this work in the general case. Mediators which
export Data Records which are substantially changed from the Data Records
received from the Original Exporter follow the guidelines in <xref
target="sec-tmpl-passthrough"/> instead.</t>
<t>Subsequent subsections deal with specific issues in Template management
that may occur at Mediators.</t>
<section title="Passing Unmodified Templates through a Mediator" anchor="sec-tmpl-passthrough">
<t>[EDITOR'S NOTE: the definition of template mappings seems really
implementation specific -- why not notionally just map IDs on each socket
to a base template? on the other hand, if we're providing a real example,
it should have concrete content in each field. reformatting is held off
until this issue is resolved.]</t>
<t>The first case is a situation where the IPFIX Mediator doesn't modify
the (Options) Template Record(s) content. A typical example is an
Intermediate Selection Process acting as distributor, which collects Flow
Records from one or more Exporters, and based on the Information Elements
content, redirects the Flow Records to the appropriate Collector. This
example is a typical case of a single network operation center managing
multiple universities: an 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.</t>
<t>As specified in <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>,
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:</t>
<list style="symbols">
<t>for each received (Options) Template Record: Template Record Flow
Keys and non Flow Keys, Template ID, Observation Domain Id, and
Transport Session Information</t>
<t>for each exported (Options) Template Record: Template Record Flow
Keys and non Flow Keys, Template ID, Collector, Observation Domain Id,
and Transport Session Information</t>
</list>
<t>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.</t>
<t>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.</t>
<t>If an incoming or outgoing Transport Session is gracefully shutdown or
reset, the (Options) Template Records corresponding to that Transport
Session MUST be removed from the Template Mapping.</t>
<t>For example, <xref target="fig-selection-example"/> displays an example
of an Intermediate Selection Process, re-distributing 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. </t>
<figure title="Intermediate Selection Process example" anchor="fig-selection-example">
<artwork><![CDATA[
Tmpl. .---------.
ID 256 | |
.---->|Collector|<==>Customer
| |#1 | A
| | |
RD=100:1 '---------'
.---------.Templ. .---------. |
| |Id | |----' .---------.
| |258 | | RD=100:2 | |
|IPFIX |------->|IPFIX |--------->|Collector|<==>Customer
|Exporter | |Mediator | Tmpl. |#2 | B
|#1 | | | ID 257 | |
| | | |----. '---------'
'---------' '---------' |
RD=100:3
Tmpl. | .---------.
ID | | |
257 '---->|Collector|<==>Customer
|#3 | C
| |
'---------'
]]></artwork>
</figure>
<t><xref target="fig-template-mapping-example"/> shows the Template Mapping for the system shown in <xref target="fig-selection-example"/>.</t>
<figure title="Template Mapping example: templates" anchor="fig-template-mapping-example">
<artwork><![CDATA[
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
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
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
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
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
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
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
Flow Keys: <series of Flow Keys>
Non Flow Keys: <series of non Flow Keys>
]]></artwork>
</figure>
<t>The Template Mapping corresponding to figure B can be displayed as:</t>
<figure title="Template Mapping example: mappings">
<artwork><![CDATA[
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry D
]]></artwork>
</figure>
<t>Alternatively, the Template Mapping may be optimized as:</t>
<figure title="Template Mapping example: mappings">
<artwork><![CDATA[
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry D
]]></artwork>
</figure>
<t>Note that all examples use Transport Sessions based on the SCTP
protocol, as simplified use cases. However, the protocol would be
important in situations such as an Intermediate Conversion Process doing
transport protocol conversion.</t>
</section>
<section title="Creating New Templates at a Mediator" anchor="sec-tmpl-new">
<t>The second case is a situation where the IPFIX Mediator generates new
(Options) Template Records as a result of the Intermediate Process.</t>
<t>In this situation, the IPFIX Mediator doesn't need to maintain a
Template Mapping, as it generates its own series of (Options) Template
Records. However, the following special case might still require a
Template Mapping, i.e. a situation where the IPFIX Mediator, typically
containing an Intermediate Conversion Process, Intermediate Aggregation
Process <xref target="I-D.ietf-ipfix-a9n"/>, or Intermediate Anonymization
Process in case of black-marker Anonymization <xref target="RFC6235"/>,
generates new (Options) Template Records based on what it receives from
the Exporter(s), and based on the Intermediate Process function. In such a
case, it's important to keep the correlation between the received
(Options) Template Records and exported Derived (Options) Template Records
in the Template Mapping. These template mappings would be kept as in <xref
target="sec-tmpl-passthrough"/>, except that the export template would not
be identical to the collection template.</t>
</section>
<section title="Information Element Ordering within Templates">
<t>[EDITOR'S NOTE: address the following: What Paul Aikten would like to
see in section 3.5 (See
http://www.ietf.org/mail-archive/web/ipfix/current/msg05969.html): What
about IE ordering? May an exporter re-order received fields? eg, two
devices sending the same information, though with the fields in a
different order. Or the mediator is extracting the same information from
two sources. That seems to be a valid scenario. eg, this reduces the
number of templates received at the collector.]</t>
</section>
<section title="Handling Unknown Information Elements">
<t>[EDITOR'S NOTE: also from Paul Aitken: What should a mediator do with a
field which it doesn't know/understand? Inevitably, exporters will be
updated without mediators keeping in step. It's also very likely that
mediators will see Enterprise-specific IEs. May a mediator re-export
unknown IEs unchanged, or should it drop them? Presumably a mediator may
report received Enterprise-specific IEs even from multiple different
Enterprises. What if an unknown field depends on the field ordering? eg,
it's a bitfield like flowKeyIndicator. Re-ordering, adding or removing
fields breaks the meaning of this field, so it can't be passed on. It can
only be used if the received fields are reported unchanged.]</t>
</section>
</section>
<section title="Preserving Original Observation Point Information" anchor="sec-oop">
<t>[EDITOR'S NOTE: Decide whether we want to address export of observation
point information without 6313. Review this section to make sure it
adequately explains how original Observation Point information can get so
complicated.]</t>
<t>Depending on the use case, the Collector in an Exporter - Mediator -
Collector structure may need to receive information about the Original
Observation Point(s), 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 in the subsections below to address this use case:
originalExporterIPv4Address and originalExporterIPv6Address. Practically,
the Original Exporters will not exporting these Information Elements.
Therefore, the Intermediate Process SHOULD report the Original Observation
Point(s) to the best of its knowledge. Note that the Configuration Data
Model for IPFIX and PSAMP <xref
target="RFC6728"/> may help.</t>
<t>In the IPFIX Mediator, the Observation Point(s) may be represented
by:</t>
<list style="symbols">
<t>A single Original Exporter (represented by the
originalExporterIPv4Address or originalExporterIPv6Address Information
Elements)</t>
<t>A list of Original Exporters (represented by the
originalExporterIPv4Address or originalExporterIPv6Address Information
Elements).</t>
<t>Any combination or list of Information Elements representing
Observation Points. For example:</t>
<list style="symbols">
<t>A list of Original Exporter interface(s) (represented by the
originalExporterIPv4Address or originalExporterIPv6Address, the
ingressInterface and/or egressInterface Information Elements,
respectively)</t>
<t>A list of Original Exporter line card (represented by the
originalExporterIPv4Address or originalExporterIPv6Address, the
lineCardId Information Elements, respectively)</t>
</list>
</list>
<t>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.</t>
<t>Any combination of the above representations is possible. For example, in
case of an Intermediate Aggregation Process, an Original Observation Point
could be composed of:</t>
<figure title="Complex Observation Point Definition Example" anchor="fig-oop-example">
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>If the Original Observation Point is composed of a list, then the IPFIX
Structured Data <xref target="RFC6313"/> MUST be used to export it from the
IPFIX Mediator.</t>
<t>The most generic way to export the Original Observation Point is to use a
subTemplateMultiList, with the semantic "exactlyOneOf". Taking the previous
example, the following encoding can be used:</t>
<figure title="Complex Observation Point Definition Example: Templates" anchor="fig-oop-templates-example">
<artwork><![CDATA[
Template Record 257: exporterIPv4Address
Template Record 258: exporterIPv4Address,
basicList of ingressInterface, flowDirection
Template Record 259: exporterIPv4Address, lineCardId, flowDirection
]]></artwork>
</figure>
<t>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.</t>
<t>When an IPFIX Mediator receives Flow Records containing the Original
Observation Point Information Element, i.e. originalExporterIPv6Address or
originalExporterIPv4Address, the IPFIX Mediator SHOULD NOT modify its
value(s) when composing new Flow Records in the general case. Known
exceptions include anonymization per <xref target="RFC6235"/> section 7.2.4
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 - Mediator(s) - Collector structure model is
out of the scope of this specification.</t>
<section title="originalExporterIPv4Address Information Element" anchor="ie-oe4">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Data Type: ">ipv4Address</t>
<t hangText="ElementId: ">TBD1</t>
</list></t>
</section>
<section title="originalExporterIPv6Address Information Element" anchor="ie-oe6">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Data Type: ">ipv6Address</t>
<t hangText="ElementId: ">TBD2</t>
</list></t>
</section>
</section>
<section title="Managing Observation Domain IDs">
<t>In any case, 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, as in
<xref target="sec-header"/> above, and section 3.1 of <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>.</t>
<t>IPFIX Mediators that do not change (Options) Template Records MUST
maintain a Template Mapping, as detailed in <xref
target="sec-tmpl-passthrough"/>, to ensure that the combination of
Observation Domain IDs and Template IDs do not collide on export.</t>
<t>For IPFIX Mediators that export New (Options) Template Records, as in
<xref target="sec-tmpl-new"/>, 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 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.</t>
<t>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.</t>
<t>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 anyway contain the Observation
Domain of the Original Exporter, the (Options) Template Record must
contain the originalObservationDomainId Information Element. 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.</t>
<section title="originalObservationDomainId Information Element" anchor="ie-ood">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Data Type: ">unsigned32</t>
<t hangText="Data Type Semantics: ">identifier</t>
<t hangText="ElementId: ">TBD3</t>
</list></t>
</section>
</section>
<section title="Timing Considerations">
<t>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 keep the
export time received from the incoming Transport Session.</t>
<t>It is RECOMMENDED that Mediators handle time using absolute timestamps
(e.g. flowStartSeconds, flowStartMilliseconds, flowStartNanoseconds),
which are specified relative to the UNIX epoch (00:00 UTC 1 Jan 1970),
where possible, rather than relative timestamps (e.g. flowStartSysUpTime,
flowStartDeltaMicroseconds), which are specified relative to protocol
structures such as system initialization or message export time.</t>
<t>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 <xref
target="iana-ipfix-assignments"/>, 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.</t>
<t>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.</t>
<t>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. Therefore, as there is
not a single rule that fits all different situations, a complete
specification of the precise rules of applying Flow Record timestamps at
IPFIX Mediators is out of the scope of this document.</t>
<t>Note that <xref target="I-D.ietf-ipfix-a9n"/> provides additional
specifications for handling of timestamps at an Intermediate Aggregation
Process.</t>
</section>
<section title="Transport Considerations">
<t>SCTP <xref target="RFC4960"/> using the PR-SCTP extension specified in
<xref target="RFC3758"/> MUST be implemented by all compliant IPFIX Mediator
implementations. TCP <xref target="RFC0793"/> MAY also be implemented by
IPFIX Mediator compliant implementations. UDP <xref target="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 <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> apply to IPFIX Mediators as
well.</t>
<t>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, or is contained through some other means.</t>
</section>
<section title="Collecting Process Considerations">
<t>Any Collecting Process compliant with <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> can receive IPFIX Messages from
an IPFIX Mediator. If the IPFIX Mediator uses <xref target="RFC6313">IPFIX
Structured Data</xref> to export Original Exporter Information as in <xref
target="sec-oop"/>, the Collecting Process MUST support <xref
target="RFC6313"/>.</t>
</section>
<section title="Specific Reporting Requirements">
<t>IPFIX provides Options Templates for the reporting on the reliability
of processes within the IPFIX Architecture. As each Mediator includes at
least one IPFIX Exporting Process, they SHOULD use the Exporting Process
Reliability Statistics Options Template, as specified in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>.</t>
<t>Analogous to the Metering Process Reliability Statistics Options
Template, also specified in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, Mediators SHOULD implement
the Intermediate Process Reliability Statistics Options Template,
specified in the subsection below.</t>
<t>The Flow Keys Options Template, as specified in <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, may require special
handling at an IPFIX Mediator as described below.</t>
<t>In addition, each Intermediate Process may have its own specific
reporting requirements (e.g. Anonymization Records as in <xref
target="RFC6235"/>, or the Aggregation Counter Distribution Options
Template as in <xref target="I-D.ietf-ipfix-a9n"/>); these SHOULD be
implemented as necessary as described in the specification for each
Intermediate Process.</t>
<section title="Intermediate Process Reliability Statistics Template">
<t>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 <xref
target="ie-impid"/>, and the ignoredRecordTotalCount Information
Element is defined in <xref target="ie-ignoredrec"/>: </t>
<texttable>
<ttcol align="left">IE</ttcol>
<ttcol align="left">Description</ttcol>
<c>observationDomainId [scope]</c>
<c>
An identifier of the Observation Domain (of messages exported by
this Mediator), locally unique to the Intermediate Process, to
which this statistics record applies.
</c>
<c>intermediateProcessId [scope]</c>
<c>
An identifier for the Intermediate Process to which this
statistics record applies.
</c>
<c>ignoredRecordTotalCount</c>
<c>
The total number of Data Records received but not processed by
the Intermediate Process.
</c>
<c>time first record ignored</c>
<c>
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 containing IPFIX Message. For this timestamp, any of the
following timestamp can be used: observationTimeSeconds,
observationTimeMilliseconds, observationTimeMicroseconds, or
observationTimeNanoseconds.
</c>
<c>time last record ignored</c>
<c>
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.
</c>
</texttable>
</section>
<section title="Flow Key Options Template">
<t>The Flow Keys Option 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 <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, and SHOULD be used by
Mediators for export as defined there.</t>
<t>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 Mediator, the Mediator
MUST export a Flow Keys Options record defining the the new set of Flow
Keys.</t>
</section>
<section title="intermediateProcessId Information Element" anchor="ie-impid">
<t><list style="hanging">
<t hangText="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; ie., and Intermediate Process may be re-started with a different ID.</t>
<t hangText="Data Type: ">unsigned32</t>
<t hangText="Data Type Semantics: ">identifier</t>
<t hangText="ElementId: ">TBD4</t>
</list></t>
</section>
<section title="ignoredRecordTotalCount Information Element" anchor="ie-ignoredrec">
<t><list style="hanging">
<t hangText="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 which were examined or otherwise handled by the Intermediate Process but which merely do not contribute to any exported Data Record due to the operations performed by the Intermediate Process.</t>
<t hangText="Data Type: ">unsigned64</t>
<t hangText="Data Type Semantics: ">totalCounter</t>
<t hangText="ElementId: ">TBD5</t>
</list></t>
</section>
</section>
<section title="Configuration Management">
<t>In general, using 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 (<xref
target="RFC6615"/> and <xref
target="RFC6727"/>) or with the Configuration Data Model
for IPFIX and PSAMP <xref target="RFC6728"/></t>
</section>
<section title="Security Considerations">
<t>As they act as both IPFIX Collecting Processes and Exporting Processes,
the Security Considerations for IPFIX Protocol <xref
target="I-D.ietf-ipfix-protocol-rfc5101bis"/> also apply to Mediators. The
Security Considerations for IPFIX Files <xref target="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.</t>
<t>By design, IPFIX Mediators are "men-in-the-middle": they intercede in the
communication between an Original Exporter (or another upstream 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
a Mediator. These are addressed in more detail in the Security
Considerations for Mediators in <xref target="RFC6183"/>.</t>
<t>Note that, while Mediators can use the exporterCertificate and
collectorCertificate Information Elements defined in <xref
target="RFC5655"/> as described in section 9.3 of <xref target="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 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.</t>
</section>
<section title="IANA Considerations">
<t>This document specifies n new IPFIX Information Elements,
originalExporterIPv4Address in <xref target="ie-oe4"/>,
originalExporterIPv6Address in <xref target="ie-oe6"/>, and
originalObservationDomainId in <xref target="ie-ood"/>, to be added to the
<xref target="iana-ipfix-assignments">IPFIX Information Element
registry</xref>. [IANA NOTE: please add the three Information Elements as
specified in the references subsections, and change TBD1, TBD2, and TBD3 in
this document to reflect the assigned identifiers.]</t>
</section>
<section title="Acknowledgments">
<t>We would like to thank the IPFIX contributors, specifically Paul Aitken
for his thorough review and Rahul Patel for his feedback and comments. This
work is materially supported by the European Union Seventh Framework
Programme under grant agreement 257315 (DEMONS).</t>
</section>
<!-- <section title="Word content">
3. Specifications
This section describes the IPFIX specifications for Mediation: more specifically, specifications for generic Intermediate Processes. Possible specific Intermediate Processes are: Intermediate Conversion Process, Intermediate Aggregation Process, Intermediate Correlation Process, Intermediate Selection Process, Intermediate Anonymization Process.
For a specific Intermediate Process, the specifications in the following references MUST be followed, on top of the specifications in this document:
- For the Intermediate Aggregation Process, the specifications in <xref target="I-D.ietf-ipfix-a9n"/> MUST be followed.
- For the Intermediate Selection Process, the specifications in <xref target="I-D.ietf-ipfix-flow-selection-tech"/> MUST be followed.
- For the Intermediate Anonymization Process, the specifications in <xref target="RFC6235"/> should be considered as guidelines as <xref target="RFC6235"/> is an experimental RFC.
Note that no specific document deals with the Intermediate Conversion Process at the time of this publication.
These new specifications, which are more specific compared than <xref target="I-D.ietf-ipfix-protocol-rfc5101bis"/>, are described with the key words described in <xref target="RFC2119"/>.
</section> -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-ipfix-protocol-rfc5101bis" ?>
<?rfc include="reference.I-D.ietf-ipfix-information-model-rfc5102bis" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3758" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5655" ?>
<?rfc include="reference.RFC.6313" ?>
<?rfc include="reference.RFC.6615" ?>
<?rfc include="reference.I-D.ietf-ipfix-flow-selection-tech" ?>
<?rfc include="reference.I-D.ietf-ipfix-a9n" ?>
<?rfc include="reference.RFC.6727" ?>
<?rfc include="reference.RFC.6728" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3917" ?>
<?rfc include="reference.RFC.3954" ?>
<?rfc include="reference.RFC.5470" ?>
<?rfc include="reference.RFC.5472" ?>
<?rfc include="reference.RFC.5476" ?>
<?rfc include="reference.RFC.5982" ?>
<?rfc include="reference.RFC.6183" ?>
<?rfc include="reference.RFC.6235" ?>
<reference anchor='iana-ipfix-assignments'>
<front>
<title>IP Flow Information Export Information Elements (http://www.iana.org/assignments/ipfix/ipfix.xml)</title>
<author surname="Internet Assigned Numbers Authority"/>
<date/>
</front>
</reference>
<reference anchor='POSIX.1'>
<front>
<title>IEEE 1003.1-2008 - IEEE Standard for Information Technology - Portable Operating System Interface</title>
<author surname="IEEE"/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:21:01 |