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]