One document matched: draft-sommer-ipfix-mediator-ext-00.xml
<?xml version="1.0"?>
<?rfc toc="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM 'reference.RFC.2119.xml'>
<!ENTITY rfc3917 SYSTEM 'reference.RFC.3917.xml'>
<!ENTITY RFC4234 SYSTEM 'reference.RFC.4234.xml'>
<!ENTITY ipfixarch SYSTEM 'reference.I-D.ietf-ipfix-architecture.xml'>
<!ENTITY ipfixproto SYSTEM 'reference.I-D.ietf-ipfix-protocol.xml'>
<!ENTITY ipfixinfo SYSTEM 'reference.I-D.ietf-ipfix-info.xml'>
<!ENTITY ipfixaggregation SYSTEM 'reference.I-D.dressler-ipfix-aggregation.xml'>
<!ENTITY ipfixreducingredundancy SYSTEM 'reference.I-D.ietf-ipfix-reducing-redundancy.xml'>
]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc footer="draft-dressler-ipfix-aggregation-04.txt"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="full3978" docName="<draft-sommer-ipfix-mediator-ext-00.txt>">
<front>
<title abbrev="Mediator-Specific IPFIX Extensions">Mediator-Specific Extensions to IPFIX Protocol and Information Model</title>
<author fullname="Christoph Sommer" initials="C." surname="Sommer">
<organization abbrev="Univ. Erlangen">University of Erlangen-Nuremberg</organization>
<address>
<postal>
<street>Department of Computer Science 7</street>
<street>Martensstr. 3</street>
<city>Erlangen</city>
<code>91058</code>
<country>Germany</country>
</postal>
<phone>+49 9131 85-27993</phone>
<email>christoph.sommer@informatik.uni-erlangen.de</email>
<uri>http://www7.informatik.uni-erlangen.de/~sommer/</uri>
</address>
</author>
<author fullname="Falko Dressler" initials="F." surname="Dressler">
<organization abbrev="Univ. Erlangen">University of Erlangen-Nuremberg</organization>
<address>
<postal>
<street>Department of Computer Science 7</street>
<street>Martensstr. 3</street>
<city>Erlangen</city>
<code>91058</code>
<country>Germany</country>
</postal>
<phone>+49 9131 85-27914</phone>
<email>dressler@informatik.uni-erlangen.de</email>
<uri>http://www7.informatik.uni-erlangen.de/</uri>
</address>
</author>
<author fullname="Gerhard Muenz" initials="G." surname="Muenz">
<organization abbrev="Univ. Tuebingen">University of Tuebingen</organization>
<address>
<postal>
<street>Computer Networks and Internet</street>
<street>Sand 13</street>
<city>Tuebingen</city>
<code>72076</code>
<country>Germany</country>
</postal>
<phone>+49 7071 29-70534</phone>
<email>muenz@informatik.uni-tuebingen.de</email>
<uri>http://net.informatik.uni-tuebingen.de/</uri>
</address>
</author>
<date month="November" year="2007"/>
<abstract>
<t>
IPFIX supports the concept of an Mediator, a device that receives, transforms, and exports data streams using IPFIX. One of the most important requirements is the reduction of the volume of IPFIX traffic by discarding and aggregating received information.
This document introduces a number of extensions to the IPFIX Protocol and IPFIX Information Model that support the export of aggregated IPFIX data. In particular, techniques are introduced that optimize the transport of descriptive information. Thus, more information can be preserved in the transmission while further reducing both the number and the size of IPFIX messages. All the proposed extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The IPFIX Mediator is intended to provide techniques and features to process IPFIX data in a Mediation Process. This process receives data streams using IPFIX. It can apply transformations or aggregation techniques and forward the resulting Flow information to an Exporting Process and, thus, to another IPFIX collector.
Flow aggregation is one of the most challenging and important operations in high-bandwidth networks. The main idea is to reduce both the number and the size of IPFIX messages.
This document introduces extensions to the IPFIX Protocol and IPFIX Information Model that support the export of aggregated IPFIX data. In particular, a new Template type is introduced and additional Information Elements are described. All these extensions allow and optimize the transport of descriptive information on aggregated IPFIX data. Thus, more information can be preserved in the transmission while further reducing both the number and the size of IPFIX messages.
All the proposed extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.
Illustrations of abstract data types are written in Augmented Backus-Naur Form (ABNF), as specified in <xref target="RFC4234"/>, extending the abstract data types defined in <xref target="I-D.ietf-ipfix-info"/>.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>
Apart from the basic terms as defined in <xref target="I-D.ietf-ipfix-protocol"/>, the following terms are used within this document:
<list style="hanging">
<t hangText="Compound Flow:">
<vspace blankLines="0" />
A Compound Flow is the result of an aggregation of one or more individual input Flows that matched an Aggregation Rule.
It might, for example, contain the total count of all packets addressed to a common subnet that were observed within a given time interval.
</t>
<t hangText="Aggregation Rule:">
<vspace blankLines="0" />
An Aggregation Rule defines the properties of a Compound Flow and the contents of the corresponding Flow Records.
Optionally, a set of filtering criteria MAY be specified in order to restrict the applicability of the rule to those Flows that show certain patterns.
</t>
</list>
</t>
</section>
<section anchor="ipfix-extension-dt" title="Rich Template">
<t>
<xref target="I-D.dressler-ipfix-aggregation" /> describes how pattern matching is used to restrict the applicability of an Aggregation Rule and how patterns define Common Properties of the resulting Compound Flows.
In order to avoid the overhead of the repeated transmissions of all Common Properties (or their identifiers) in all Flow Records, a new Template Set, the "Rich Template Set" is introduced.
This Template Set allows an Exporting Process to simultaneously declare and transmit Common Properties to a receiver.
</t>
<t>
The basic format of a Rich Template Set is shown in <xref target="RichTemplateSet" />.
It is the same as that of a Template Set defined in <xref target="I-D.ietf-ipfix-protocol" />, except for a different Set ID.
The format of individual Rich Template Records, however, differs from that of Template Records and is shown in <xref target="RichTemplate" />.
<figure anchor="RichTemplateSet" title="Rich Template Set Format">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Rich Template Record 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Rich Template Record N |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The Rich Template Set field definitions are as follows:
<list style="hanging">
<t hangText="Set ID">
<vspace blankLines="0" />
Type of this Template Set. A Set ID value of 4 is proposed for the Rich Template Set.
</t>
<t hangText="Length">
<vspace blankLines="0" />
Total length of this set in bytes, as defined in <xref target="I-D.ietf-ipfix-protocol"/>.
</t>
<t hangText="Padding">
<vspace blankLines="0" />
OPTIONAL padding, as defined in <xref target="I-D.ietf-ipfix-protocol" />.
</t>
</list>
<figure anchor="RichTemplate" title="Rich Template Record Format">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Count | Common Properties ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Field 1 Specifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Field N Specifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data 1 Specifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data M Specifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data 1 Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data M Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The Rich Template Record field definitions are as follows:
<list style="hanging">
<t hangText="Template ID">
<vspace blankLines="0" />
Template ID of this Rich Template Record. As defined in <xref target="I-D.ietf-ipfix-protocol"/>, this value MUST be greater than 255.
</t>
<t hangText="Field Count">
<vspace blankLines="0" />
Number of regular fields that will be sent in subsequent Data Records using this Template, as defined in <xref target="I-D.ietf-ipfix-protocol"/>.
</t>
<t hangText="Data Count">
<vspace blankLines="0" />
Number of fixed-value fields that will be sent in this Template.
</t>
<t hangText="Common Properties ID">
<vspace blankLines="0" />
Contains an identifier that can be referred to by commonPropertiesId Information Elements, as introduced in <xref target="I-D.ietf-ipfix-reducing-redundancy"/>.
</t>
<t hangText="Field N Specifier">
<vspace blankLines="0" />
Information Element identifier, Field length and an Enterprise Number (if applicable) of field N. Refer to <xref target="I-D.ietf-ipfix-protocol"/> for more information on Field Specifiers.
</t>
<t hangText="Data M Specifier">
<vspace blankLines="0" />
Same as "Field N Specifier", but used for Common Properties of all Data Records of this Template. Together with Data M Value, a similar encoding like TLV (type-length-value) is achieved.
</t>
<t hangText="Data M Value">
<vspace blankLines="0" />
Bit representation of a Common Property as would be transmitted in a Data Record.
</t>
</list>
</t>
<t>
<xref target="field-modifier-export" /> illustrates the relationship between field modifiers and patterns on the one hand, and the resulting regular and fixed-value fields in the Rich Template on the other hand.
It can be seen that the analyzer is able to deduce all instructions of the Aggregation Rule considering the structure of the Rich Template, except the combination "discard without pattern" that does not result in any field.
</t>
<texttable anchor="field-modifier-export" title="Relation between field modifiers, Flow Records, and Rich Templates">
<ttcol>field modifier</ttcol><ttcol>pattern</ttcol><ttcol>field in Flow Record</ttcol><ttcol>fixed-value field in Rich Template</ttcol>
<c>discard</c><c>no</c><c>N/A</c><c>N/A</c>
<c>discard</c><c>yes</c><c>N/A</c><c>yes, contains pattern</c>
<c>keep</c><c>no</c><c>yes</c><c>N/A</c>
<c>keep</c><c>yes</c><c>yes, if pattern specifies a range of values</c><c>yes, contains pattern</c>
<c>mask</c><c>no</c><c>yes, IP network address</c><c>N/A</c>
<c>mask</c><c>yes</c><c>yes, IP network address</c><c>yes, contains pattern</c>
</texttable>
<t>
Assume, for example, the concentrator was given the Aggregation Rule shown in <xref target="example-rule-1" />.
</t>
<texttable anchor="example-rule-1" title="Example Rule">
<ttcol>IPFIX Field</ttcol><ttcol>Filtering</ttcol><ttcol>Aggregation</ttcol>
<c>sourceIPv4Address</c><c>192.0.2.0/28</c><c>discard</c>
<c>destinatonTransportPort</c><c></c><c>keep</c>
<c>packetDeltaCount</c><c></c><c>aggregate</c>
</texttable>
<t>
Based on the Aggregation Rule, the concentrator would now first send a corresponding Rich Template Record as shown in <xref target="RichTemplate.ex.dt" />.
</t>
<texttable anchor="RichTemplate.ex.dt" title="Rich Template used">
<ttcol>Field</ttcol><ttcol>Value</ttcol>
<c>Template ID</c><c>10001</c>
<c>Field Count</c><c>2</c>
<c>Data Count</c><c>2</c>
<c>Common Properties ID</c><c>0</c>
<c>Field 1 Type</c><c>Destination Port</c>
<c>Field 2 Type</c><c>Packets</c>
<c>Data 1 Type</c><c>Source IP Prefix</c>
<c>Data 2 Type</c><c>Source IP Mask</c>
<c>Data 1 Value</c><c>192.0.2.0</c>
<c>Data 2 Value</c><c>28</c>
</texttable>
<t>
Assume further that the concentrator receives the Flow Records shown in <xref target="RichTemplate.ex.in" />.
</t>
<texttable anchor="RichTemplate.ex.in" title="Incoming Flows">
<ttcol>Source IP</ttcol><ttcol>Source Port</ttcol><ttcol>Destination IP</ttcol><ttcol>Destination Port</ttcol><ttcol>Packets</ttcol>
<c>192.0.2.1</c><c>64235</c><c>192.0.2.101</c><c>80</c><c>10</c>
<c>192.0.2.2</c><c>64236</c><c>192.0.2.102</c><c>110</c><c>10</c>
<c>192.0.2.3</c><c>64237</c><c>192.0.2.103</c><c>80</c><c>10</c>
<c>192.0.2.101</c><c>64238</c><c>192.0.2.1</c><c>80</c><c>10</c>
<c>192.0.2.102</c><c>64239</c><c>192.0.2.2</c><c>80</c><c>10</c>
</texttable>
<t>
The concentrator would then export Data Records of this type, which contain the Compound Flows resulting from aggregation.
Note that the Flows' Common Property, having a source IP address in 192.0.2.0/28, was already transmitted in the Rich Template Record and is thus not included in Data Records.
The exported Data Records, shown in <xref target="RichTemplate.ex.agg" />, only contain the aggregated packet counts and the destination port, the latter being the only discriminating Flow Key property.
</t>
<texttable anchor="RichTemplate.ex.agg" title="Aggregated Flows">
<ttcol>Destination Port</ttcol><ttcol>Packets</ttcol>
<c>80</c><c>20</c>
<c>110</c><c>10</c>
</texttable>
</section>
<section anchor="ipfix-extension-ipn" title="Abstract data type ipv4Network">
<t>
Currently, the transport of IP network information as specified by IPFIX is done using separate fields for the network address and the corresponding mask.
We propose a new abstract data type ipv4Network that represents the common notation of IP networks: address/mask.
<figure align='left'>
<preamble>
The ipv4Network abstract data type extends the abstract data type ipv4Address to allow a concatenated unsigned8 specifying the prefix length.
Alternatively, Information Elements based on the ipv4Network abstract data type MAY be transmitted using reduced size encoding to transmit only the network part of an IPv4 address.
In ABNF-style notation, the syntax can be summed up as follows:
</preamble>
<artwork align='center' type='abnf'><![CDATA[
ipv4Network = ipv4Address unsigned8
ipv4Network =/ *4( unsigned8 )
]]></artwork>
<postamble>
</postamble>
</figure>
</t>
<t>
Although using an ipv4Network field instead of two separate fields for prefix and mask will not reduce the length of resulting Flow Records, it eases the work of the aggregator:
With ipv4Network, the comparison of subnet addresses requires only one field lookup per Flow Record instead of two.
Furthermore, using the abstract data type ipv4Network reduces the Template size by one field equalling four octets.
Applications such as IPFIX Aggregation benefit from ipv4Network if network addresses are frequently exported.
</t>
</section>
<section anchor="ipfix-extension-pr" title="Abstract data type portRanges">
<t>
For some applications it might be useful to restrict the applicability of an Aggregation Rule to Flows with source or destination port being of a specific set of port numbers.
In an Aggregation Rule, such a set of port numbers can be specified as a pattern.
However, the current IPFIX Information Model does not define any data type that allows transmitting a set of port numbers, which is necessary in order to export the pattern as a Common Property of the resulting Compound Flows.
Therefore, the new abstract data type portRanges for a list of port ranges is defined in this section.
<figure align='left'>
<preamble>
The abstract data type portRanges is a finite-length concatenation of unsigned16 value pairs, each consisting of the port range's first and last port number.
Data types basing on portRanges MAY also be cast down to unsigned16 using reduced size encoding to represent a single Port.
Hence, the transportSourcePort and transportDestinationPort data types, currently based on the unsigned16 abstract data type, can also be parsed as portRanges-based data types.
In ABNF-style notation, the syntax can be summed up as follows:
</preamble>
<artwork align='center' type='abnf'><![CDATA[
portRanges = *(unsigned16 unsigned16)
portRanges =/ unsigned16
]]></artwork>
<postamble>
An Information Element basing on portRanges MAY also be used as a variable-length Information Elements by prefixing it with a one-octet or three-octet length specifier as defined in <xref target="I-D.ietf-ipfix-protocol"/>.
</postamble>
</figure>
</t>
<t>
<xref target="ipfix-extension-pr-ex" /> shows some encoding examples with portRanges.
</t>
<texttable anchor="ipfix-extension-pr-ex" title="PortRanges Examples">
<ttcol>Port Ranges</ttcol><ttcol>Octets</ttcol><ttcol>Hexadecimal Representation</ttcol>
<c>80</c><c>2</c><c>0050</c>
<c>1:7</c><c>4</c><c>0001 0007</c>
<c>80, 443 </c><c>8</c><c>0050 0050 01BB 01BB</c>
<c>1:7, 256:1024</c><c>8</c><c>0001 0007 0100 0400</c>
<c>20, 80, 443</c><c>12</c><c>0014 0014 0050 0050 01BB 01BB</c>
<c>1:7, 80, 443</c><c>12</c><c>0001 0007 0050 0050 01BB 01BB</c>
</texttable>
</section>
<section anchor="excludedpropertiesid" title="excludedPropertiesId Information Element">
<t>
The IPFIX Information Model <xref target="I-D.ietf-ipfix-info"/> defines the commonPropertiesId Information Element, which can be used to link to information which several Flows have in common.
</t>
<t>
Similarly, the excludedPropertiesId shall be defined to link to a set of Common Properties which a Flow does explicitly not exhibit. An ElementId of 239 is proposed for this Information Element.
</t>
<t>
The excludedPropertiesId works like a boolean "and not" operation on the linked properties. This means that, if an excludedPropertiesId refers to a set of Common Properties which in turn specifies excluded properties, these transitively referenced properties are to be treated as if directly referenced via a commonPropertiesId element and, hence, as being present in the Flow in question.
</t>
<t>
The excludedPropertiesId can, for example, be used when a hierarchy of Aggregation Rules with a "preceding rule" semantic, as introduced in <xref target="I-D.dressler-ipfix-aggregation" />, is configured in an IPFIX Aggregator.
</t>
<t>
<xref target="cp2" /> illustrates the use of Common Property definitions and the linking to these definitions with Information Elements of types commonPropertiesId (CP) and excludedPropertiesId (EP). In this example, two rules are defined in the aggregator: Rule 1 matches Flows with a sourceIPv4Address of 192.0.2.1, Rule 2 matches Flows with a destinationIPv4Address of 192.0.2.2. Furthermore, Rule 1 is configured to precede Rule 2 in a hierarchy of rules, i.e. Flows that matched Rule 1 will never match Rule 2.
</t>
<t>
In order to communicate this fact to a receiver, each Aggregation Rule is transmitted as two sets of Common Properties. One set of properties (shown on the right hand side of <xref target="cp2" />) directly transmits a rule's filtering criteria. The other set of properties (shown on the left hand side) refers via a commonPropertiesId to all properties that a Compound Flow exhibits, as well as via an excludedPropertiesId to all that the Compound Flow does not exhibit.
</t>
<t>
The Flow depicted at the bottom of <xref target="cp2" /> thus communicates a source port of 80, a destination port of 65432, a destination IP of 192.0.2.2 and a source IP of "not 192.0.2.1". However, besides the transmission of this Flow in one Data Record, previous transmissions (and the successful reception) of four Option Templates, four Option Data Records and one Template are required to communicate this information.
</t>
<t>
<figure anchor="cp2" title="Using excludedPropertiesId to communicate a rule hierarchy">
<artwork align="center"><![CDATA[
Rule 1:
+########+------+ +######+---------------+
# CP=101 # CP=1 |<-----------># CP=1 # SRC=192.0.2.1 |
+########+------+ +######+---------------+
^
.--------------------'
Rule 2: v
+########+------+------+ +######+---------------+
# CP=102 # EP=1 | CP=2 |<----># CP=2 # DST=192.0.2.2 |
+########+------+------+ +######+---------------+
^
'-------------------.
Flow: v
+--------+-----------+--------+
| SPT=80 | DPT=65432 | CP=102 |
+--------+-----------+--------+
]]></artwork>
</figure>
</t>
</section>
<section anchor="precedingRulePropertiesId" title="precedingRulePropertiesId Information Element">
<t>
The only aspect in which the precedingRulePropertiesId Information Element differs from the excludedPropertiesId Information Element introduced in <xref target="excludedpropertiesid" /> is that transitive references are handled differently.
</t>
<t>
Unlike the excludedPropertiesId, the precedingRulePropertiesId does not work like a boolean "and not" operation on the linked properties. This means that, if a precedingRulePropertiesId refers to a set of Common Properties which in turn specifies excluded properties, these transitively referenced properties are to be treated as being excluded from the Flow in question, too.
</t>
<t>
Analogous to excludedPropertiesId, the precedingRulePropertiesId (PP) Information Element can be used to communicate the hierarchy of rules introduced in the example of <xref target="excludedpropertiesid" />. As illustrated in <xref target="cp3" />, the amount of data transmitted is now significantly smaller, while communicating the exact same information: A source port of 80, a destination port of 65432, a destination IP of 192.0.2.2 and a source IP of "not 192.0.2.1". Besides the transmission of the Flow in one Data Record it only requires the previous transmissions (and the successful reception) of two Rich Templates.
</t>
<t>
<figure anchor="cp3" title="Using precedingRulePropertiesId to communicate a rule hierarchy">
<artwork align="center"><![CDATA[
Rule 1:
+---------------+
| SRC=192.0.2.1 |<---. (Rich Template 1234, CP=101)
+---------------+ |
|
|
Rule 2: |
+---------------+--------+
| DST=192.0.2.2 | PP=101 | (Rich Template 1235)
+---------------+--------+
Flow:
+--------+-----------+
| SPT=80 | DPT=65432 | (Based on Rich Template 1235)
+--------+-----------+
]]></artwork>
</figure>
</t>
</section>
<section title="Security considerations">
<t>
As all methods described in this document are merely variations on methods already introduced in <xref target="I-D.ietf-ipfix-protocol"/>, the same rules regarding exchange of Flow information apply.
</t>
</section>
<section title="IANA Considerations">
<t>
Use of the Rich Template Set requires one new IPFIX Set ID to be assigned.
Use of excludedPropertiesId, precedingRulePropertiesId, as well as use of a data type basing on ipv4Network or on portRanges requires one new IPFIX Information Element identifier each to be assigned.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&RFC4234;
&ipfixproto;
</references>
<references title="Informative References">
&ipfixreducingredundancy;
&ipfixinfo;
&ipfixaggregation;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:18 |