[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04 05
Network Working Group F. Dressler
Internet-Draft C. Sommer
Expires: July 31, 2005 University of Erlangen
G. Muenz
University of Tuebingen
January 27, 2005
IPFIX Aggregation
<draft-dressler-ipfix-aggregation-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IPFIX Aggregation describes a methodology for reducing the amount of
measurement data exchanged between monitoring devices (IPFIX
exporters) and analyzers (IPFIX collectors). Using aggregation
techniques, measurement information of similar flows is aggregated
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 1]
Internet-Draft IPFIX Aggregation January 2005
into one metaflow. The degree of similarity can be defined using
aggregation rules. To achieve further reduction of the amount of
data exchanged while still transmitting all required information to
the collector, the IPFIX protocol and Information Model is slightly
extended to allow two new data types and a new template / template
set.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aggregation Techniques . . . . . . . . . . . . . . . . . . . . 3
2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Explicit Rules . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Special Fields . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Shared Properties . . . . . . . . . . . . . . . . . . 6
2.3 Application Examples . . . . . . . . . . . . . . . . . . . 7
2.3.1 Charging . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Intrusion Detection . . . . . . . . . . . . . . . . . 7
3. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 PrecedingRule . . . . . . . . . . . . . . . . . . . . . . 8
3.2 PortRanges . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Data Template . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Security considerations . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 2]
Internet-Draft IPFIX Aggregation January 2005
1. Introduction
Flow measurement in high speed, large scale networks can quickly
produce an amount of data that can no longer be handled by a central
monitoring station without having been preprocessed. Flow
aggregators try to alleviate this problem by selectively discarding
data and merging flows into bigger metaflows, thus reducing both the
number of flows sent and the amount of data carried in each flow
record. This document proposes ways of designing and implementing
IPFIX aggregators and introduces extensions to IPFIX necessary for
doing so.
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 [RFC2119].
2. Aggregation Techniques
2.1 Architecture
Aggregation of measurement data may take place at two possible
stages:
An internal aggregator (see Figure 1) might be implemented as a
process running in an IPFIX enabled device, aggregating raw data
collected by multiple metering processes and exporting it as
metaflows.
An external aggregator, as shown in Figure 2, might be appropiate
where the collecting device cannot be refitted with an aggregator or
if cascaded aggreagtion is desired. External aggregators, called
concentrators in IPFIX terminology, receive flows from lower-level
concentrators or measurement devices' exporters and export the
aggregated metaflows to a higher-level concentrator or a monitoring
station.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 3]
Internet-Draft IPFIX Aggregation January 2005
+------------------------------------------+ +--------------+
| IPFIX-enabled device .---. .---. | | |
| .--------------------. | A | | | | .-->| Analyzer |
| | Metering Process 1 |-. | g | | E | | | | |
| `--------------------' | | g | | x | | | +--------------+
| | | r | | p |---'
| . '-->| e | | o | |
| . | g |-->| r | |
| . .-->| a | | t |---.
| | | t | | e | | | +--------------+
| .--------------------. | | o | | r | | '-->| |
| | Metering Process N |-' | r | | | | | Concentrator |
| `--------------------' `---' `---' | .-->| |
+------------------------------------------+ : +--------------+
Figure 1: Internal Aggregation
: +--------------+ +-----------------------+ +--------------+
'-> | | Concentrator | | |
| Concentrator |-. | .---. .---. .---. | .-->| Analyzer |
.-> | | | | C | | A | | | | | | |
: +--------------+ | | | o | | g | | E | | | +--------------+
'--->| l | | g | | x |---'
| | l | | r | | p | |
| | e |-->| e |-->| o |-|
| | c | | g | | r | |
.--->| t | | a | | t |---.
+--------------+ | | | o | | t | | e | | | +--------------+
| | | | | r | | o | | r | | '-->| |
| IPFIX device |-' | | | | r | | | | | Concentrator |
| | | `---' `---' `---' | .-->| |
+--------------+ +-----------------------+ : +--------------+
Figure 2: External Aggregation
2.2 Procedure
2.2.1 Explicit Rules
Regarding methods of aggregation, a simple, rule-based approach is
proposed: The concentrator is supplied a list of user-defined rules.
Each rule consists of multiple aggregation instructions describing
o The type of IPFIX field the aggregation instruction refers to
(e.g. "Destination IP")
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 4]
Internet-Draft IPFIX Aggregation January 2005
o A matching pattern (e.g. 10.10.0.0/16). In order for an incoming
IPFIX record to be aggregated according to a given rule, all of
its aggregation instruction's patterns need to be matched by the
incoming record's corresponding fields' values.
o A granularity modifier (e.g. "keep field"). If the aggregation
instruction refers to a regular field type, the modifier can
either be "discard field" or "keep field". If the aggregation
instruction refers to a field of type "IP address", the modifier
can also only selectively discard bits of the IP address by
applying a network mask. If the aggregation instruction refers to
one of the special field types mentioned in Section 2.2.2 the
modifier takes a fixed value of "aggregate" and the aggregation
instruction acts according to Section 2.2.2.
This way each rule also unambiguosly defines
o A minimal set of IPFIX fields an incoming record needs to
transport to potentially match this rule: All fields mentioned in
the rule's aggregation instructions MUST be present.
o The template used when exporting flows matching this rule: Each
field mentioned in the rule's aggregation instructions that does
not have its granularity modifier set to "discard" will be present
in all flows that were aggregated according to this rule. Other
fields of an incoming flow that have no matching aggregation
instruction are neither considered nor exported.
Regarding treatment of incoming flow records that matched a given
rule, two possible implementations can be thought of:
First-match
An incoming flow record is sequentially checked against each rule.
If all fields of the flow record match the corresponding fields of
the aggregation rule, the rule's granularity modifiers are applied
and the flow is aggregated. No further processing of this flow
takes place. Because in this case a receiver of aggregated flows
needs to be aware of the order in which rules were checked,
exported flows carry an additional field that points to flows
matching a preceding rule. See Section 3.1 for a possible
implementation.
Each possible match
An alternative implementation might check each incoming record
against every rule. If all fields of the flow record match the
corresponding fields of an aggregation rule, a copy of the flow
has the rule's granularity modifiers applied, is aggregated and
processing of the original flow continues with the next rule. In
this case the order of rules need not be transmitted.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 5]
Internet-Draft IPFIX Aggregation January 2005
2.2.2 Special Fields
Fields that describe properties of the flow itself rather than
properties of packets that made up the flow receive special
treatment: A flow's begin-timestamp is set to the minimum of the
comprising flows' timestamps, Packet and byte counters of aggregated
flows are summed up, etc. All fields (see also the IPFIX information
model [I-D.ietf-ipfix-info]) that require special processing are
summarized in Table 1.
+--------------------------------+---------------------------------+
| Field | Action |
+--------------------------------+---------------------------------+
| # packets | sum of all aggregated flows |
| # bytes | sum of all aggregated flows |
| # flows | sum of all aggregated flows |
| timestamp of first seen packet | minimum of all aggregated flows |
| timestamp of last seen packet | maximum of all aggreagted flows |
+--------------------------------+---------------------------------+
Table 1: Information with Implicit Aggregation Rules
2.2.3 Shared Properties
Matching patterns of fields (e.g., an IP address matching a
subnetwork) constitute shared properties of exported flows. Such
shared properties are equal for each flow and , therefore, MAY be
exported as regular IPFIX fields. They SHOULD, however, be
transmitted as shared properties using the Data Template proposed in
Section 3.3. No separate transmissions of aggregation instructions
need take place.
Let us consider an example ruleset:
1. Match Source Port 80.
Match Destination IPs in 10.10.0.0/16, apply mask /24.
Aggregate # packets.
2. Aggregate # packets.
The first rule aggregates all flows to a destination in 10.10.x.0/24
with source port equal to 80. The shared properties of all these
flows are the source port (80) and the destination address (one in
10.10.x.0). Thus, this ruleset provides quick packet counters for
outbound HTTP traffic in subnets 10.10.x.0, providing an additional
packet counter for all other flows.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 6]
Internet-Draft IPFIX Aggregation January 2005
2.3 Application Examples
2.3.1 Charging
Monitoring and accouting for charging applications requires to save
information about each individual end system. Further information
about each particular flow is not required. Therefore, aggregation
rules are appropriate if the address of the end system is retained.
An example ruleset might consist of the following instructions:
1. Match Destination IP in 10.10.0.0/16, keep field.
Aggregate # packets.
2. Match Source IP in 10.10.0.0/16, keep field.
Aggregate # packets.
Thus, aggregated meta flows will be created for all inbound and
outbound traffic of the network managed, separated by direction and
host. Protocol and port information will be discarded.
2.3.2 Intrusion Detection
If monitoring is employed for further analysis in terms of intrusion
detection, i.e. anomaly detection, rule-based intrusion detection,
etc, information about used protocols at transport layer as well as
at application layer are mostly required. On the other hand, the
analysis will typically work on the basis of subnetworks instead of
single hosts because of the amount of data to process. Information
about the traffic between individual end systems is required if
suspicious transmissions were alread detected.
An example ruleset might consist of the following instructions:
1. Match Destination IP in 10.10.0.0/16, keep field
Match any Source IP, mask /24
Match any Protocol, keep field
Match any Destination Port, keep field
Aggregate # packets.
Thus, aggregated meta flows will be created for all packets to hosts
in particular networks. The destination port and the protocol will
be preserved and the source port will be discarded.
3. Data Export
After having a rule's granularity modifiers applied, all data records
that matched a rule comprise the same fields, so for each rule
exactly one template can be used. In order to efficiently transmit
aggregated flows, however, three extensions to IPFIX are required:
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 7]
Internet-Draft IPFIX Aggregation January 2005
o data type: PrecedingRule
o data type: PortRanges
o template / template set: Data Template
3.1 PrecedingRule
When doing rule-based aggregation and creating metaflows on a
first-match basis, like proposed in Section 2.2, the order in which
rules are checked needs to be made clear to the receiver. Because of
the one-to-one mapping between rules and template IDs, communicating
the order of rules is as simple as embedding the preceding rule's
template ID into exported metaflows.
A new data type, PrecedingRule, which is based on the unsigned16
abstract data type and can be embedded into a DataTemplate as
presented in Section 3.3, serves exactly this purpose. This way the
concentrator is implicitely sent aggregation rules or, at least, the
actually used aggregation rules and their order.
3.2 PortRanges
As the current draft contains no data type to transmit port lists or
port ranges, this section defines a new abstract data type for a list
of port ranges.
PortRanges is a finite length string of unsigned32 values, each
consisting of an unsigned16 start port followed by an unsigned16 end
port specification.
PortRanges MAY be used as a variable-length data type as defined in
[I-D.ietf-ipfix-protocol].
Data types basing on PortRanges MAY also be cast down to unsigned16
to represent a single Port. Therefore, the transportSourcePort and
transportDestinationPort data types, currently based on the
unsigned16 abstract data type, may be replaced by PortRanges.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 8]
Internet-Draft IPFIX Aggregation January 2005
+---------------+--------+---------------------------------+
| Ports | Length | Hexadecimal Representation |
+---------------+--------+---------------------------------+
| 80 | 2 | 0050 |
| 1:7 | 4 | 0001 0007 |
| 80, 443 | 8 | 0050 0050 01BB 01BB |
| 1:7, 256:1024 | 8 | 0001 0007 0100 0400 |
| 20, 80, 443 | 12 | 0014 0014 0050 0050 01BB 01BB |
| 1:7, 80, 443 | 12 | 0001 0007 0050 0050 01BB 01BB |
+---------------+--------+---------------------------------+
Table 2: PortRanges Examples
3.3 Data Template
When doing rule based aggregation of flows, the resulting metaflows
share many field values. In order to avoid the overhead of
repeatedly transmitting these common values of all flows that matched
a given rule, a new template type is introduced.
This template type, termed a "data template", allows the sender to
both declare and define common properties of Data Sets based on it.
The basic format of a Data Template Set is the same as that of a
Template Set and - for the sake of completeness - is shown in
Figure 3. The format of individual Template definitions, however,
differs from that of the standard Template and is shown in Figure 4
.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 9]
Internet-Draft IPFIX Aggregation January 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data Template 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data Template N |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Data Template Set Format
The Data Template Set field definitions are as follows:
Set ID
Type of this template set. A set ID value of 4 is proposed for
the data template set.
Length
Total length of this set in bytes.
Padding
Optional Padding to fill the set to a word boundary. MUST consist
of null-bytes and be at most seven bytes in length
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 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Field 1 Type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 10]
Internet-Draft IPFIX Aggregation January 2005
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Field N Type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data 1 Type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data M Type |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data 1 Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data M Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Data Template Format
The Data Template field definitions are as follows:
Template ID
See the description of a Type 3 Template Set in
[I-D.ietf-ipfix-protocol]
Field Count
Number of regular Fields that will be sent in subsequent Data Sets
using this Template.
Data Count
Number of fixed-value Fields that will be sent in this Template.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 11]
Internet-Draft IPFIX Aggregation January 2005
Reserved
Reserved, MUST be 0.
Field N Type
Type identifier, Type length and an enterprise number (if needed)
of field N. Refer to [I-D.ietf-ipfix-protocol] for more
information on Field Types
Data M Type
Same as "Field N Type", but used for common properties of all Data
Sets that use this Template. Together with Data M Value, a
similar encoding like TLV is achieved.
Data M Value
Bit representation of a common property as would be transmitted in
a Data Set.
3.4 Example
In this example we assume the concentrator was given the following
aggregation rules:
1. Match source IPs in 10.0.0.0/23, discard field.
Match any destination port, keep field.
Aggregate # packets.
2. Pass through all other flows
We further assume the concentrator receives the following flow
records:
+------------+------------+-------------+-------------+-------------+
| Source IP | Source | Destination | Destination | Packets |
| | Port | IP | Port | |
+------------+------------+-------------+-------------+-------------+
| 10.0.0.1 | 64235 | 10.0.0.10 | 80 | 10 |
| 10.0.1.2 | 64236 | 10.0.0.11 | 110 | 10 |
| 10.0.0.3 | 64237 | 10.0.0.12 | 80 | 10 |
| 10.0.2.4 | 64238 | 10.0.0.13 | 80 | 10 |
| 10.0.2.5 | 64239 | 10.0.0.14 | 80 | 10 |
+------------+------------+-------------+-------------+-------------+
Table 3: Incoming Flows
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 12]
Internet-Draft IPFIX Aggregation January 2005
Given the example rules and flows from above, the concentrator would
now use one Template to send all flows that matched no given rule and
were thus not aggregatable:
+------------+------------+-------------+-------------+-------------+
| Source IP | Source | Destination | Destination | Packets |
| | Port | IP | Port | |
+------------+------------+-------------+-------------+-------------+
| 10.0.2.4 | 64238 | 10.0.0.13 | 80 | 10 |
| 10.0.2.5 | 64239 | 10.0.0.14 | 80 | 10 |
+------------+------------+-------------+-------------+-------------+
Table 4: Outgoing Flows I
The second Data Set uses a Data Template to send all flows that
matched our aggregation rule. Note that the flows' common property,
a Source IP of 10.0.0.0/23, was already transmitted in the template,
so besides the packet count only the flows' discriminating property,
their destination port, is sent in the data records:
+------------------+---------+
| Destination Port | Packets |
+------------------+---------+
| 80 | 20 |
| 110 | 10 |
+------------------+---------+
Table 5: Outgoing Flows II
4. Security considerations
As all methods described in this document are merely variations on
methods already introduced in [I-D.ietf-ipfix-protocol], the same
rules regarding exchange of flow information apply.
5. References
5.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
5.2 Informative References
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specifications",
Internet-Draft draft-ietf-ipfix-protocol-07, December
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 13]
Internet-Draft IPFIX Aggregation January 2005
2004.
[I-D.ietf-ipfix-info]
Meyer, J., Quittek, J. and S. Bryant, "Information Model
for IP Flow Information Export",
Internet-Draft draft-ietf-ipfix-info-05, October 2004.
[RFC3917] Quittek, J., Zseby, T., Claise, B. and S. Zander,
"Requirements for IP Flow Information Export", RFC 3917,
October 2004.
Authors' Addresses
Falko Dressler
University of Erlangen
Department of Computer Science 7
Martensstr. 3
Erlangen 91058
Germany
Phone: +49 9131 85-27914
Email: dressler@informatik.uni-erlangen.de
URI: http://www7.informatik.uni-erlangen.de/
Christoph Sommer
University of Erlangen
Department of Computer Science 7
Martensstr. 3
Erlangen 91058
Germany
Email: sichsomm@stud.informatik.uni-erlangen.de
Gerhard Muenz
University of Tuebingen
Computer Networks and Internet
Auf der Morgenstelle 10C
Tuebingen 72076
Germany
Phone: +49 7071 29-70534
Email: muenz@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 14]
Internet-Draft IPFIX Aggregation January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 15]
Html markup produced by rfcmarkup 1.120, available from
https://tools.ietf.org/tools/rfcmarkup/