IPFIX Working Group A. Kobayashi
Internet-Draft K. Ishibashi
Expires: September 3, 2006 K. Yamamoto
NTT PF Lab.
D. Matsubara
Hitachi
March 2, 2006
The reference model of IPFIX concentrators
draft-kobayashi-ipfix-concentrator-model-01.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 September 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a reference model for IPFIX concentrators. An
IPFIX concentrator is an intermediate node between IPFIX monitoring
devices and traffic collectors. It has several capabilities, such as
collecting and storing flow records, selecting and aggregating flow
records, and exporting flow records.
Kobayashi, et al. Expires September 3, 2006 [Page 1]
Internet-Draft IPFIX concentrators March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Selection Process . . . . . . . . . . . . . . . . . . . . 4
2.2. Aggregation Process . . . . . . . . . . . . . . . . . . . 4
2.3. Storing Process . . . . . . . . . . . . . . . . . . . . . 4
2.4. Extraction Function . . . . . . . . . . . . . . . . . . . 4
2.5. Traffic Collector . . . . . . . . . . . . . . . . . . . . 4
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. External Reference Model . . . . . . . . . . . . . . . . . 6
3.2. Internal Reference Model . . . . . . . . . . . . . . . . . 7
4. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 8
4.2. Selection Process . . . . . . . . . . . . . . . . . . . . 8
4.3. Aggregation Process . . . . . . . . . . . . . . . . . . . 8
4.4. Reporting Process and Exporting Process . . . . . . . . . 9
4.5. Storing Process . . . . . . . . . . . . . . . . . . . . . 9
5. New Information Elements . . . . . . . . . . . . . . . . . . . 10
5.1. averageActiveTime . . . . . . . . . . . . . . . . . . . . 10
5.2. minimumActiveTime . . . . . . . . . . . . . . . . . . . . 11
5.3. maximumActiveTime . . . . . . . . . . . . . . . . . . . . 11
5.4. synCount . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. ackCount . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. finCount . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.7. pshCount . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.8. urgCount . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. rstCount . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. flowCount . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Aggregation Model by Cascade Connection . . . . . . . . . 14
6.2. Distribution Model . . . . . . . . . . . . . . . . . . . . 15
6.3. Analyzing Model of Storage Data . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Kobayashi, et al. Expires September 3, 2006 [Page 2]
Internet-Draft IPFIX concentrators March 2006
1. Introduction
The scalability of IPFIX collecting processes is limited. In large-
scale networks, a single central collecting process might not be able
to process all flow records exported by IPFIX devices in the network.
A way to increase scalability is sharing the load of processing flow
records with a set of IPFIX concentrators that aggregate flow records
received from different IPFIX devices and export the aggregated
records.
An IPFIX concentrator is located between one or more IPFIX exporting
process and one or more IPFIX collecting processes. An IPFIX
concentrators is composed of collecting processes, metering processes
and exporting processes. It acts as collector towards exporting
processes sending flow records and it acts as exporter towards
collectors that receive flow records exported by the concentrator.
This dual-role architecture allows cascading concentrators and
adjusting the number of IPFIX concentrators to the size of a given
network.
This document proposes a reference model for IPFIX concentrators and
describes the key component of this architecture.
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].
Kobayashi, et al. Expires September 3, 2006 [Page 3]
Internet-Draft IPFIX concentrators March 2006
2. Terminology
The definitions of basic IPFIX and PSAMP terms such as Collecting
Process, Reporting Process and Exporting Process are identical with
those in the [I-D.ietf-psamp-framework] and [RFC3917]. Other than
the above terminology, the following terminology is used in this
document.
2.1. Selection Process
The IPFIX concentrator's selection process is similar to that in
PSAMP devices which is described in [I-D.ietf-psamp-framework].
However, its selection process differs from the following
capabilities. This process in PSAMP devices has two types of
selection functions: filtering and sampling. In addition, the
filtering function has two types of filtering methods: field-match
filtering and hash-based selection. This process in IPFIX
concentrator has only the field-match filtering function. This
filter selects flow records based on flow record content.
2.2. Aggregation Process
This process creates aggregated flow records, in accordance with
aggregation rules that are described in [I-D.dressler-ipfix-
aggregation], from flow records that are the output of the selection
process.
2.3. Storing Process
This process selects specified information elements by the storing
rules from the output of collecting process and stores these flow
records in a database. Information elements that are described in
[I-D.ietf-ipfix-info] are specified in storing rules. In addition,
the source ID and Export Time in the header of IPFIX messages are
specified in the storing rules.
2.4. Extraction Function
This function is assigned to the collecting process. The collecting
process enables extraction of flow records from the storage database.
The IPFIX concentrator that enables this function SHOULD be provided
with the storing process and storage database.
2.5. Traffic Collector
The traffic collector collects flow records from IPFIX monitoring
devices or IPFIX concentrators. It also performs several roles
together with applications, for example, accounting, traffic
Kobayashi, et al. Expires September 3, 2006 [Page 4]
Internet-Draft IPFIX concentrators March 2006
engineering, anomaly detection, and tracing the traffic of DDoS
attacks to identify the attacker. However, it does not have a
forwarding function to another IPFIX enabled node. The capability of
the traffic collector is beyond the scope of this document.
Kobayashi, et al. Expires September 3, 2006 [Page 5]
Internet-Draft IPFIX concentrators March 2006
3. Reference Model
The reference model for the IPFIX concentrators is shown in the
figure below. This model covers the connection of the External
Reference Model and IPFIX concentrator. The Internal Reference Model
describes the software process architecture in the IPFIX
concentrator.
3.1. External Reference Model
Connection methods of IPFIX monitoring devices, IPFIX concentrator,
and Traffic Collector are indicated in the following figure. Being
locating between IPFIX-enabled nodes, several functions can be
applied to the total system. IPFIX concentrator receives flow
records by the IPFIX protocol and forwards flow records to another
IPFIX-enabled node by the IPFIX protocol. By using the IPFIX
protocol at both the sender and receiver, the flexibility of
connection methods is enabled. If either the previous node or
following node of a device is the IPFIX concentrator, that node does
not need to have special protocol functions. That node only connects
the other IPFIX-enabled node through the IPFIX protocol. In
addition, IPFIX concentrator can have manage multiple IPFIX protocol
sessions between these nodes. The IPFIX concentrator receives flow
records through two IPFIX sessions and distributes flow records
through three IPFIX sessions, as shown in this figure. It acts as an
IPFIX proxy or IPFIX exporter instead of an IPFIX monitoring device.
It is described in detail in section 5 with an example scenario.
+------------+
+------------+ |Traffic |
|IPFIX | |Collector |
|monitoring | .--->| |
|devices |----. | +------------+
+------------+ | +------------+ | +------------+
'--->|IPFIX |---' |Traffic |
+------------+ .--->|concentrator|------->|Collector |
|IPFIX | | | |---. | |
|concentrator|----' +------------+ | +------------+
| | | +------------+
+------------+ '--->|IPFIX |
|concentrator|
| |
+------------+
Figure A: connection methods of IPFIX concentrator
Previous IPFIX-enabled nodes could be IPFIX monitoring devices or
Kobayashi, et al. Expires September 3, 2006 [Page 6]
Internet-Draft IPFIX concentrators March 2006
another IPFIX concentrator. The following IPFIX-enabled nodes could
be Traffic Collector or another IPFIX concentrator.
3.2. Internal Reference Model
The following figure indicates six components (collecting, selection,
aggregation, reporting, exporting, and storing) within the IPFIX
concentrator. These components are mapped to three process as the
IPFIX architecture in the [RFC3917]. The Collecting Process matches
the IPFIX Collecting Process and the chain of Selection Process,
Aggregation Process, and Reporting Process matches the IPFIX Metering
Process. The Exporting Process matches the IPFIX Exporting Process.
The reporting and exporting process is similar to each process within
the PSAMP device [I-D.ietf-psamp-framework].
+----------------------------------------------------+
| IPFIX concentrator |
| |
| .----------. .---------. .-----------. |
Flow ------>|Collection|-->|Selection|-->|Aggregation| |
Record| |Process | |Process | |Process |--. |
| | | '---------' '-----------' | |
| | | | |
| | | .-----------. | |
| | |<--------------- |DataBase | | |
| | | | | | |
| | | .---------. | | | |
| | | |Storing | | | | |
| | |-->|Process |-->| | | |
| '----------' '---------' '-----------' | |
| | |
| .-----------------------------------------------' |
| | |
| | .----------. .---------. |
| '-->|Reporting |-->|Exporting|------------------------> Flow
| |Process | |Process | | Record
| '----------' '---------' |
| |
+----------------------------------------------------+
Figure B: Key components within IPFIX concentrator
Each process is associated by a common identifier in the IPFIX
concentrator. This method is similar to PSAMP associations in
[I-D.ietf-psamp-sample-tech].
Kobayashi, et al. Expires September 3, 2006 [Page 7]
Internet-Draft IPFIX concentrators March 2006
4. Components
The key components of the concentrator are the collecting, storing,
selection, aggregating, and exporting processes.
Each component has managed objects that are controlled and referred
to through SNMP. They are similar to [I-D.ietf-psamp-mib]. These
components of each concentrator are also controlled by other nodes.
The managed objects that are controlled are described in
[I-D.kobayashi-ipfix-concentrator-mib].
4.1. Collecting Process
The collecting process receives flow records from IPFIX monitoring
devices or a previous IPFIX concentrator. The instance of this
process is created according to IPFIX session. This process has
capabilities that are described in [I-D.ietf-ipfix-protocol]. It
manages the exporter address and received template. It also forwards
received flow records with IPFIX header information to multiple
selection processes or storing processes. In addition, this process
perform the function of extracting from database. If this function
is available, the instance of this process is created. This process
extracts past flow records in accordance with instructions and
forwards these to the selection process. In such a case, an
instruction has the start and end times of flow records that are
extracted.
4.2. Selection Process
The selection process receives flow records from collecting
processes. This process has a filtering function and selects flow
records that are matched under given conditions. Prior to receiving
flow records, this process has instruction pattern data that is
defined by the user. It specifies how the flow records are treated
by this process. If some fields in the flow record match the
instruction pattern, this process selects flow records with all
fields and forwards these to the aggregation process. For example,
this process selects flow records to prevent the following IPFIX-
enabled node from being counted twice within the same flow traffic.
4.3. Aggregation Process
The aggregation process gathers flow records within a given time
interval and then distinguishes flow records that have common
properties. If values of a given key field are the same, that means
these flow records have common properties. This process merges flow
records that have a common property and creates a aggregated flow
record. Therefore, for example, aggregated flow records have an
Kobayashi, et al. Expires September 3, 2006 [Page 8]
Internet-Draft IPFIX concentrators March 2006
aggregated counter which indicates the number of packets. These
functions are defined in accordance with the IPFIX aggregation rule
in [I-D.dressler-ipfix-aggregation]. This process has instructions
that are user defined prior to receiving flow records. It indicates
fields that should become aggregated flow keys and other fields that
should be kept or discarded. In addition, these instruction rules
include information elements that should be added to aggregated flow
records. The aggregated flow MAY need to complement information that
is discarded during the aggregation process. For example, the
aggregated flow has "observedFlowTotalCount"and "minActiveTime"
fields. The first field is the number of flow records within a
aggregated flow, the second field is the minimum active time of any
flow within a aggregated flow. Both fields complement the
information that is discarded by aggregation. These information
elements are described in next section.
4.4. Reporting Process and Exporting Process
The reporting and exporting processes forward flow records to the
next IPFIX- enabled node. These processes manage the reporting
template and make an IPFIX datagram. The "Export time" and "source
id" of IPFIX header information can be either of the following
methods. The time of "Export time" field depends on whether the
IPFIX concentrator is a proxy or not. From the point of view of the
traffic collector, if this IPFIX concentrator is a proxy, it becomes
the most recent time of the originally received data. If it is not a
proxy, "Export time" becomes the export time of the concentrator. In
the first case, this process needs to obtain the originally received
data from the aggregating process. If IPFIX concentrator is not a
proxy, its "Source ID" should be zero. If IPFIX concentrator is a
proxy and aggregated according to different "Source ID" values, it
should be zero. The "Export time" and "Source ID" values above take
over from the aggregation process.
4.5. Storing Process
The storing process selects specified information elements by the
storing instruction from the input flow records. Prior to receiving
flow records, this process has instructions that are configured by
the user, which indicate whether each field should be stored or
discarded. The field modifier indicate "keep" or "discard", which is
similar to the instruction of the aggregation process. The field
modifier specifies how these information elements are treated by the
process. This field modifier is applied to information element
within flow record and header information of IPFIX messages. The
header information of IPFIX messages are sourceID and Export time.
This header information MAY be used when IPFIX datagrams are made of
past flow records.
Kobayashi, et al. Expires September 3, 2006 [Page 9]
Internet-Draft IPFIX concentrators March 2006
5. New Information Elements
This section describes that new information elements that are not
defined in [I-D.ietf-ipfix-info]. These information elements are
added instead of lost information by aggregation. It is main problem
for Traffic Collector that several informations are lost during
aggregation. This problem could be alleviated by adding other
information elements. These information elements are added by the
aggregation process and they helps Traffic Collector to analyze
aggregated flow. For example, by monitoring average, minimum and
maximum active time of individual flow in aggregated flow, traffic
trend could be seen in the whole network traffic. Other than those,
each ratio among "synCount", "ackCount" and "rstCount" could be
preliminary data for detecting anomaly traffic like TCP SYN attack.
The "synCount" means the Flows counter in aggregated flow. The
aggregation process counts Flows that have "tcpControlBits" which SYN
bit set to 1. Actual value of this counter can not be evaluated,
because "tcpControlBits" means at least one observed packets in this
Flow have the corresponding TCP bit. But, Combination analysis of
these elements and other information elements would help Traffic
Collector to analyze. The set of these new Information Elements is
listed in the table below.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| xxx| averageActiveTime | xxx| finCount |
| xxx| minimumActiveTime | xxx| pshCount |
| xxx| maximumActiveTime | xxx| urgCount |
| xxx| synCount | xxx| rstCount |
| xxx| ackCount | xxx| flowCount |
+-----+---------------------------+-----+---------------------------+
5.1. averageActiveTime
Description:
This information element indicates average time of difference
value between flow start time and end time of each flows that are
included in aggregated flow. It is the number of milliseconds.
It is created from flow time stamp information elements. There are
"flowStartSeconds", "flowEndSeconds", "flowStartMilliSeconds",
"flowEndMilliSeconds", "flowStartSysUpTime" and
"flowEndSysUpTime".
Abstract Data Type: unsigned32
ElementId: xxx
Status: current
Units: milliseconds
Kobayashi, et al. Expires September 3, 2006 [Page 10]
Internet-Draft IPFIX concentrators March 2006
5.2. minimumActiveTime
Description:
This information element indicates minimum time of difference
value between flow start time and end time of each flows that are
included in aggregated flow. It is the number of milliseconds.
It is created from flow time stamp information elements. There are
"flowStartSeconds", "flowEndSeconds", "flowStartMilliSeconds",
"flowEndMilliSeconds", "flowStartSysUpTime" and
"flowEndSysUpTime".
Abstract Data Type: unsigned32
ElementId: xxx
Status: current
Units: milliseconds
5.3. maximumActiveTime
Description:
This information element indicates maximum time of difference
value between flow start time and end time of each flows that are
included in aggregated flow. It is the number of milliseconds.
It is created from flow time stamp information elements. There are
"flowStartSeconds", "flowEndSeconds", "flowStartMilliSeconds",
"flowEndMilliSeconds", "flowStartSysUpTime" and
"flowEndSysUpTime".
Abstract Data Type: unsigned32
ElementId: xxx
Status: current
Units: milliseconds
5.4. synCount
Description:
The total number of Flows Records that have "tcpControlBits" which
SYN bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.5. ackCount
Kobayashi, et al. Expires September 3, 2006 [Page 11]
Internet-Draft IPFIX concentrators March 2006
Description:
The total number of Flows Records that have "tcpControlBits" which
ACK bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.6. finCount
Description:
The total number of Flows Records that have "tcpControlBits" which
FIN bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.7. pshCount
Description:
The total number of Flows Records that have "tcpControlBits" which
PSH bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.8. urgCount
Description:
The total number of Flows Records that have "tcpControlBits" which
URG bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.9. rstCount
Kobayashi, et al. Expires September 3, 2006 [Page 12]
Internet-Draft IPFIX concentrators March 2006
Description:
The total number of Flows Records that have "tcpControlBits" which
RST bit set to 1 are included in aggregated flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
5.10. flowCount
Description:
The total number of Flows Records that is included in aggregated
flow.
Abstract Data Type: unsigned64
ElementId: xxx
Status: current
Units: Flows
Kobayashi, et al. Expires September 3, 2006 [Page 13]
Internet-Draft IPFIX concentrators March 2006
6. Example Scenarios
The reference model of the IPFIX concentrator is shown in the figure
below. This covers various scenarios to connect IPFIX concentrators.
6.1. Aggregation Model by Cascade Connection
The following figure indicates a cascade connection of IPFIX
concentrators. In the first step, an IPFIX concentrator receives
flow records from IPFIX monitoring devices and then creates
aggregated low-level flow records. For example, the first step is
prefix mask aggregation. Next, IPFIX concentrator receives
aggregated flow records and aggregates further. For example, the
second step is the aggregation of the BGP next-hop address and
exporter address. After this, the collector receives high-level
aggregated flow records and then stores them. This method enables
step-by-step aggregation of flow records without overloading a single
node.
+----------+ +------------+
|IPFIX | |IPFIX |
|monitoring|---->|concentrator|---.
|devices | |*1 | |
+----------+ +------------+ | +------------+ +---------+
'--->|IPFIX | |Traffic |
+----------+ +------------+ .--->|concentrator|---->|Collector|
|IPFIX | |IPFIX | | |*2 | | |
|monitoring|---->|concentrator|---' +------------+ +---------+
|devices | |*1 |
+----------+ +------------+
Figure C: Cascade connection of IPFIX concentrators
Devices indicated by "*1" create aggregate flow records in accordance
with the prefix mask of the source IP address and the destination IP
address. The device indicated by "*2" aggregates flow records in
accordance with the exporter address and BGP next-hop address.
Kobayashi, et al. Expires September 3, 2006 [Page 14]
Internet-Draft IPFIX concentrators March 2006
6.2. Distribution Model
The following figure indicates the connection between the IPFIX
concentrator and Traffic collectors. This enables load balancing for
storing a huge volume of data. The IPFIX concentrator distributes
flow records in accordance with specified parameters. For example,
this parameter may be the input interface index. When another
application searches stored flow records, it needs to know which
Traffic Collector stored specific flow records. In that case, this
application can search these records by accessing the MIB of the
IPFIX concentrator.
+---------+
+----------+ |Traffic |
|IPFIX | |Collector|
|monitoring| .--->| |
|devices |----. | +---------+
+----------+ | +------------+ | +---------+
'--->|IPFIX |---' |Traffic |
+----------+ .--->|concentrator|------->|Collector|
|IPFIX | | |*1 |---. | |
|monitoring|----' +------------+ | +---------+
|devices | | +---------+
+----------+ '--->|Traffic |
|Collector|
| |
+---------+
Figure D: Distribution of flow records by IPFIX concentrator
The device indicated by "*1" distributes flow records in accordance
with the input interface index and performs load balancing.
Kobayashi, et al. Expires September 3, 2006 [Page 15]
Internet-Draft IPFIX concentrators March 2006
6.3. Analyzing Model of Storage Data
The following figure indicates the connection between the IPFIX
concentrator and Traffic Collectors. The IPFIX concentrator enables
analysis of any traffic using past flow records. The IPFIX
concentrator extracts past flow records from a database and forwards
them to the Traffic Collector. The Traffic Collector allows the
comparison of current flow records to past flow records and analyzes
the comparison. In addition, aggregated flow records that are stored
in the Traffic Collector are searched for more specific flow records
that are stored in the IPFIX concentrator.
+---------+
+----------+ |Traffic |
|IPFIX | |Collector|
|monitoring| .--->| |
|devices |----. | +---------+
+----------+ | +------------+ | +---------+
'--->|IPFIX |---' |Traffic |
+----------+ .--->|concentrator|------->|Collector|
|IPFIX | | |*1 |---. | |
|monitoring|----' +------------+ | +---------+
|devices | | +---------+
+----------+ '--->|Traffic |
|Collector|
| |
+---------+
Figure E: Analysis of past flow records by using IPFIX concentrator
The device indicated by "*1" extracts flow records from its own
database and forwards the flow records to each Traffic Collector and
analyzes the flow records.
Kobayashi, et al. Expires September 3, 2006 [Page 16]
Internet-Draft IPFIX concentrators March 2006
7. Security Considerations
The IPFIX concentrator uses the IPFIX protocol. Security
considerations about flow information are described in [I-D.ietf-
ipfix-protocol].
Kobayashi, et al. Expires September 3, 2006 [Page 17]
Internet-Draft IPFIX concentrators March 2006
8. IANA Considerations
This document has no actions for IANA.
Kobayashi, et al. Expires September 3, 2006 [Page 18]
Internet-Draft IPFIX concentrators March 2006
9. Acknowledgments
Many thanks to J. Quittek for providing valuable comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.dressler-ipfix-aggregation]
Dressler, F., Sommer, C., and G. Munz, "IPFIX
Aggregation", draft-dressler-ipfix-aggregation-01.txt
(work in progress) , July 2005.
[I-D.ietf-ipfix-info]
Quittek, J., Bryant, S., Claise, B., and J. Meyer,
"Information Model for IP Flow Information Export",
draft-ietf-ipfix-info-11.txt(work in progress) ,
September 2005.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-19 (work in progress) ,
September 2005.
[I-D.ietf-psamp-framework]
Duffield, N., "A Framework for Packet Selection and
Reporting", draft-ietf-psamp-framework-10.txt ,
January 2005.
[I-D.ietf-psamp-mib]
Dietz, T. and B. Claise, "Definitions Managed Objects for
Packet Sampling", draft-ietf-psamp-mib-05.txt (work in
progress) , October 2005.
[I-D.ietf-psamp-sample-tech]
Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", draft-ietf-psamp-sample-tech-07.txt ,
July 2005.
Kobayashi, et al. Expires September 3, 2006 [Page 19]
Internet-Draft IPFIX concentrators March 2006
[I-D.kobayashi-ipfix-concentrator-mib]
Kobayashi, A., Ishibashi, K., Yamamoto, K., and D.
Matsubara, "Managed Objects of IPFIX concentrator",
draft-kobayashi-ipfix-concentrator-mib-01.txt (work in
progress) , March 2006.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export(IPFIX)",
October 2004.
Kobayashi, et al. Expires September 3, 2006 [Page 20]
Internet-Draft IPFIX concentrators March 2006
Authors' Addresses
Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net
Keisuke Ishibashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-3407
Email: ishibashi.keisuke@lab.ntt.co.jp
Yamamoto Kimihiro
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81-422-59-2514
Email: yamamoto.kimihiro@lab.ntt.co.jp
Daisuke Matsubara
Hitachi, Ltd., Central Reseach Laboratory
1-280 Higashi-koigakubo
Kokubunji-shi, Tokyo 185-8601
Japan
Phone: +81-42-323-1111
Email: d-matuba@crl.hitachi.co.jp
Kobayashi, et al. Expires September 3, 2006 [Page 21]
Internet-Draft IPFIX concentrators March 2006
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 (2006). 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.
Kobayashi, et al. Expires September 3, 2006 [Page 22]