IPFIX Working Group A. Kobayashi Internet-Draft H. Nishida Intended status: Informational NTT PF Lab. Expires: August 24, 2008 C. Sommer F. Dressler Univ. Erlangen E. Stephan France Telecom February 21, 2008 Problems with Flow Collection in Large-Scale Networks draft-kobayashi-ipfix-large-ps-01 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 August 24, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kobayashi, et al. Expires August 24, 2008 [Page 1] Internet-Draft Problem Statement in large NW February 2008 Abstract Flow measurement techniques have been developed in order to cope with increasing bandwiths. Flow measurement is currently being used as a popular method for monitoring large networks, e.g. at Internet Service Providers or multinational corporations, for accounting, management, and security purposes. To construct the measurement system for such networks, the biggest challenge is scalability. Whereas packet sampling functions in current flow measurement solutions such as NetFlow/sFlow/IPFIX help to approach this issue, some problems still remain. This document describes such open issues, which a flow-based measurement system might encounter in large-scale networks. The results are intended to be used to define and to develop an IPFIX Mediator device. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Flow-Based Traffic Measurement . . . . . . . . . . . . . . . . 6 3.1. Flow-Based Measurement in Service Provider Networks . . . 6 3.2. Flow-Based Measurement in Integrated Networks . . . . . . 6 4. Approaches to Scalability . . . . . . . . . . . . . . . . . . 8 4.1. Adjusting Sampling Rates . . . . . . . . . . . . . . . . . 8 4.2. Exporting Aggregated Flows from Original Exporters . . . . 8 4.3. A Hierarchical Model of Flow Collection . . . . . . . . . 9 4.4. A Load Balancing Technique for Flow-based Measurement . . 9 5. Problems with using IPFIX Mediators . . . . . . . . . . . . . 11 5.1. Implementing Load Balancing . . . . . . . . . . . . . . . 11 5.2. Loss of Observation Point Information . . . . . . . . . . 11 5.3. Loss of Base Time Information . . . . . . . . . . . . . . 12 5.4. Loss of Option Template Information . . . . . . . . . . . 12 5.5. Observation Domain ID and Template ID Management . . . . . 13 5.6. Sessions Management . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Kobayashi, et al. Expires August 24, 2008 [Page 2] Internet-Draft Problem Statement in large NW February 2008 1. Introduction Flow-based measurement has significantly improved the quality of traffic measurement methods available for service provider networks. It is quickly becoming one of the essential operation tools in many networks. In particular, monitoring operations in large-scale networks need flow-based measurement techniques to ensure stable and efficient operations. However, network providers might soon encounter problematic situations because of scalability issues. With ever increasing traffic volume in large networks, the number of exported Flow Records becomes huge. In addition, Flow information is required for multiple purposes. Maintaining the scalability of a flow-based measurement system and at the same time offering Flows in the manner required for purposes such as Traffic Engineering, Troubleshooting, Accounting, and Security is difficult. This document provides a problem description, and thus, the requirements for an extension to IPFIX, the IPFIX Mediator. The IPFIX applicability draft [I-D.ietf-ipfix-as] describes a variety of applications that use the IPFIX protocol [RFC5101]. In most networks, the flexibility of the IPFIX protocol meets the requirements of a flow-based measurement system. However, from the viewpoint of large-scale, fast-growing networks, there are still some unresolved problems. This document describes such problematic cases in large-scale networks. 1.1. Scope of this document This document focuses on problems related to IPFIX Mediation after describing solutions to achieve scalability. Kobayashi, et al. Expires August 24, 2008 [Page 3] Internet-Draft Problem Statement in large NW February 2008 2. Terminology The following terminology related to IPFIX Mediation is used in this document. Therefore, terms defined in the IPFIX terminology are capitalized in this document. IPFIX Mediator An IPFIX Mediator hosts at least one Exporting Process and one Collecting Process. IPFIX Mediator is a generic name of several devices, such as an IPFIX Proxy, an IPFIX Masquerading Proxy, an IPFIX Distributor, and an IPFIX Concentrator. The IPFIX Concentrator and the IPFIX Proxy are described in [RFC3917]. Basically, IPFIX Mediators have two types of mediation functions, as follows. * IPFIX Protocol Mediation This type of IPFIX Mediator forwards input Flow Records to upstream Collectors. An IPFIX Mediator does not change the set of Flow Records nor the value or Template of Flow Records. IPFIX Protocol Mediation relays from receiving IPFIX sessions to exporting IPFIX sessions. For example, it works to act as a proxy for Original Exporters, or convert IPFIX Transport Session from UDP to SCTP, or to duplicate one session to multiple sessions. Example devices for this type are the IPFIX Proxy and the IPFIX Distributor. * Flow Mediation This type of IPFIX Mediator creates a new set of Flow Records from input Flow Records. A Flow Mediation indicates Flow aggregation, selection, and modification. A Flow modification indicates two different kinds of modifications. One is changing the value of specified Information Elements. The second is changing the Template and record structure by adding/ deleting specified Information Elements. Example devices for this type are the IPFIX Masquerading Proxy and the IPFIX Concentrator. An IPFIX Mediator are composed of these functions. The composite of these functions can be considered in many ways as one of the devices of IPFIX Mediators. Original Exporter An Original Exporter hosts Observation Points where IP packets can be directly observed, as opposed to an IPFIX Mediator which can Kobayashi, et al. Expires August 24, 2008 [Page 4] Internet-Draft Problem Statement in large NW February 2008 act as intermediate Exporter. IPFIX Distributor An IPFIX Distributor replicates Flow Records and forwards them to multiple Collectors. In addition, an IPFIX Distributor classifies Flow Records based on the value of specified Information Elements and forwards the classified Flow Records to dedicated Collectors. An IPFIX Distributor does not change the value or template of Data Records. IPFIX Masquerading Proxy An IPFIX Masquerading Proxy exports Flow Records to a different network domain at the edge of a network domain. From a Collector's point of view, an IPFIX Masquerading Proxy acts as an Original Exporter, just like an IPFIX Proxy. In addition, an IPFIX Masquerading Proxy reviews whether received Flow Records are passed forward to a Collector to hide the network topology or privacy information. An IPFIX Masquerading Proxy has at least one function of filtering, modifying, and anonymizing functions. Kobayashi, et al. Expires August 24, 2008 [Page 5] Internet-Draft Problem Statement in large NW February 2008 3. Flow-Based Traffic Measurement 3.1. Flow-Based Measurement in Service Provider Networks Flow-based measurement methods are one of the most popular measurement methods of network service providers. Usually, an operator measures traffic at several Observation Points for a specific purpose, typically sampling packets with rates ranging from 1/10,000 to 1/1,000. This value depends on the several factors, such as the capacity of the management network, the available storage and speed of the Collector, and the load of the routers/switches. This section describes some use cases of flow-based measurement in service provider networks. o In gateway routers, exchange traffic between neighboring AS is monitored using flow-based measurement. The result helps with the planning of peering policies and with traffic engineering to optimize the network resources. o In server-side routers, the traffic toward a specific customer's server is measured. The collected data is used to detect traffic anomalies, such as distributed denial-of-service attacks and packet scans. Furthermore, this data is valuable for network forensics, when customers ask to investigate their server traffic. o In access routers connected to the broadband customers, the traffic of each customer is measured to profile them. Operators pay special attention to customers that use a lot of network bandwidth by using P2P file exchange applications. Results give good feedback about the implemented billing policy. As described above, the network providers are making extensive use of flow-based measurements. The number of Observation Points in the networks can even be increased to improve on the effectiveness of these methods. In the near future, we anticipate that the advanced features of IPFIX, such as monitoring wide-area traffic exchange behavior and QoS performance will accelerate IPFIX utilization. The increasing amount of the traffic that is brought about by broadband users might have an impact on measurement parameters such as the sampling rate or the granularity of Flows. 3.2. Flow-Based Measurement in Integrated Networks Recently several networks seem to shift towards Integrated Networks, such as the Internet and MPLS, which include IPv4, IPv6 and VPN traffic. These sorts of Flow Records need to be analyzed separately and from different perspectives. However, handling them separately without improving the capability of the Collector is difficult. If Kobayashi, et al. Expires August 24, 2008 [Page 6] Internet-Draft Problem Statement in large NW February 2008 the Original Exporter can not classify specific Flow Records based on the Flow contents and distribute them, a single Collector needs to be able to handle all kinds of Flow Records. Aside from the Original Exporter, other devices assisting in this function would thus be necessary. Kobayashi, et al. Expires August 24, 2008 [Page 7] Internet-Draft Problem Statement in large NW February 2008 4. Approaches to Scalability The volume of traffic on ordinary service provider networks has been increasing year by year. As the sizes of networks become larger, the amount of Flow Records becomes greater. The huge amount of Flow Records has been burdening management networks and Collecting Processes. Maintaining scalability is difficult as a particular network grows. Generally, large-scale networks already have multiple 10 Gb/s links, their total traffic exceeding 100 Gb/s. In the near future, broadband users' traffic will increase by approximately 50% per year according to [TRAFGRW]. When operators monitor traffic of 500 Gb/s with a sampling rate of 1/1000, the amount of exported Flow Records from Exporters could exceed 50 kFlows/s. This value reaches beyond the ability of a single Collector. It should be noted that the current sampling rate might become infeasible for Exporters within the next five years. We expect to encounter this problem within the next five years in large-scale networks. In addition, network operators need to monitor the overall wide-scale traffic exchange, and investigate detailed traffic behavior when traffic incidents happen. Achieving this seems to be difficult for a single Collector because of the huge amount of Flow Records. To that end, the network operators can consider several solutions. The next sections describe how operators can cope with such a huge amount of Flow Records using available solutions of NetFlow/sFlow/ IPFIX. 4.1. Adjusting Sampling Rates Adjusting the sampling rate definitely reduces the amount of Flow Records, and a flow-based measurement system can thus easily adapt to the ability of the Collecting and Exporting Processes. However, in that case, Flows with small traffic volumes could easily get lost. When traffic incidents happen, network operators can no longer investigate traffic behavior. While traffic volumes on networks continue to increase, network operators will not be able to maintain the sampling rates currently used. In the near future, there is a possibility that flow-based measurement systems will not be able to detect traffic anomalies which can currently be detected. 4.2. Exporting Aggregated Flows from Original Exporters The simplest type of Flows being those comprised of all packets having the same 5-tuple of protocol, source and destination IP addresses, and source and destination port numbers. On the other Kobayashi, et al. Expires August 24, 2008 [Page 8] Internet-Draft Problem Statement in large NW February 2008 hand, choosing the shorter Flow Key, such as 3-tuple or 2-tuple, or single Flow Key such as network prefix or peering AS number or BGP Next-Hop creates more aggregated Flow Records. This solution is especially useful for measurements of traffic exchange in an entire network domain, and easily to adjust the performance of Collector. However, network operators can no longer monitor traffic behavior in- depth just like 5-tuple. 4.3. A Hierarchical Model of Flow Collection In large-scale networks, creating a hierarchical collection system by using IPFIX Concentrators can prove to be very useful. Collecting the aggregated Flow Records exported by IPFIX Concentrators from whole networks enables measuring traffic behavior of entire networks. In addition, if IPFIX Concentrators store the received Flow Records, and then the stored Flow Records are allowed to be retrieved by other devices, this architecture might actually become a most useful distributed-collection system. As described in [I-D.dressler-ipfix-aggregation], in the case of a measurement system consisting of both aggregating and non-aggregating Exporters, an IPFIX Concentrator can assist the latter by aggregating received Flow Records to any granularity. 4.4. A Load Balancing Technique for Flow-based Measurement In general, load balancing allows work of Collectors to be divided. Classifying Flow Records based on the value of specified Information Elements can prove to be very useful to achive scalability. In the simplest case, Original Exporters export all Flow Records without requiring an additional function. An intermediate device (the IPFIX Mediator) classifies Flow Records based on the value of specified Information Elements and exports the classified Flow Records to individual Collectors. In particular, in an integrated network situation, the nature of each network is different, although several kinds of networks, such as VPNs and the Internet, share a physical network. Load balancing allows individual Collectors related to each network to analyze traffic behavior for each purpose. Kobayashi, et al. Expires August 24, 2008 [Page 9] Internet-Draft Problem Statement in large NW February 2008 An IPFIX Mediator could, for example, distribute Flow Records based on the value of RD (Route Distinguisher), ingress IF, peering AS number, or BGP next hop, which identify the customer. As shown in the following figure, the IPFIX Mediator distributes Flow Records based on RD. This system allows each customer's traffic to be inspected independently. .---------. |Traffic | .---->|Collector|<===> Customer#A | |#1 | | '---------' RD=100:1 .---------. | .--------. |IPFIX |----' .---------. |IPFIX | |Mediator | RD=100:2 |Traffic | |router#1|--------->| |--------->|Collector|<===> Customer#B | | | | |#2 | '--------' | |----. '---------' '---------' | RD=100:3 | .---------. | |Traffic | '---->|Collector|<===> Customer#C |#3 | '---------' Figure A: Load Balacing Technique for Flow Based Measurement. Kobayashi, et al. Expires August 24, 2008 [Page 10] Internet-Draft Problem Statement in large NW February 2008 5. Problems with using IPFIX Mediators As described in previous section, less demanding sampling rates make small flows invisible, while aggregation of Flow Records make e.g. port number or IP address invisible. Even if traffic grows, network operators would like to maintain the same sampling rate and granularity of flow as much as possible. On the other hand, hierarchical structure and load balancing techniques are useful for creating a scalable collection system. These solutions can be implemented by using IPFIX Mediators, such as IPFIX Concentrators and IPFIX Distributors. In this section, we focus on the problems related to the use of IPFIX Mediators. 5.1. Implementing Load Balancing There currently is no description of a classification function in IPFIX. According to the current specification, Exporters send all Flow Records to multiple Collectors and Collectors drop uninteresting Flow Records to reduce their load. That definitely wastes network resources. The load balancing technique of flow-based measurement needs a classification function, not simple round-robin processing, because each individual Collector needs to analyze the classified Flow Records based on the nature of the examined network. 5.2. Loss of Observation Point Information Both the Exporter IP address indicated by the source IP address of the IPFIX session as well as the Observation Domain ID included in the IPFIX header would likely be lost in the process of mediation that is performed by an IPFIX Mediator. Exporter IP address and Observation Domain ID indicate the Observation Point information from the viewpoint of the entire network domain. Such information is necessary for guaranteeing the continuity of the work of the top level Collector. Even if an IPFIX Mediator could, with some new mechanism, notify Collectors of this Observation Point information, older Collectors might drop it. These Collectors would then wrongly assume that the IP address of the IPFIX Mediator is the one of the Original Exporter. The Collector, however, needs to recognize the precise Observation Point whether Flow Records go through an IPFIX Mediator or not. Kobayashi, et al. Expires August 24, 2008 [Page 11] Internet-Draft Problem Statement in large NW February 2008 In the following figure, a Collector could identify 2 Exporters with IP addresses of 10.1.1.3 and 10.1.1.2, respectively. The Collector, however, needs to somehow recognize Router#1 and Router#2, which are the Original Exporters. Defined notification methods which can be interpreted by Collectors and Mediators are thus necessary. .--------. .--------. |IPFIX | |IPFIX | |Router#1|--------->|Mediator|---+ | | | | | '--------' '--------' | .---------. IP:10.1.1.1 IP:10.1.1.3 '----->| | ODID:10 ODID:0 |Collector| +----->| | .--------. | '---------' |IPFIX | | |Router#2|-----------------------' | | '--------' IP:10.1.1.2 ODID:20 Figure B: Loss of Observation Point Information. 5.3. Loss of Base Time Information The Export Time field included in the IPFIX header indicates the base time for Flow Records. In IPFIX Information Elements, described in [RFC5102], there are delta time fields which indicate the time difference from the value of the Export Time field. If Flow Records include any delta time fields and the IPFIX Mediator overwrites the Export Time field when sending IPFIX messages, the delta time fields become meaningless and, because Collectors can not recognize this situation, wrong time values are propagated. 5.4. Loss of Option Template Information In some cases, depending on the implementation of the IPFIX Mediators, the information that is reported by Option Templates could also be lost. If, for example, the sampling rate is not communicated to Collectors, a Collector would miscalculate the traffic volume. This situation might bring crucial problems. Even if an IPFIX Mediator were to just relay received Option Template Information, the value of its scope fields would become meaningless in the context of a different session. It should be noted that the minimal information to be communicated by an IPFIX Mediator needs to be defined. Kobayashi, et al. Expires August 24, 2008 [Page 12] Internet-Draft Problem Statement in large NW February 2008 5.5. Observation Domain ID and Template ID Management The Observation Domain ID is locally unique to the Exporting Process in IPFIX Mediator, just like the Template ID is unique on the basis of the Observation Domain ID. These renewed identifiers should be managed using Transport Session Information of Collecting Process. If IPFIX Mediators would not manage the relations among these identifiers and received Transport Session Information, IPFIX Mediators would, for example, relay wrong values for the scope fields of Option Template and "Template Withdraw Message". In most cases, a Collector would not be able to interpret the Template ID of "Template Withdraw Message" and the scope fields of Option Template. The Collector would then shut down the IPFIX Session. 5.6. Sessions Management How an IPFIX Mediator maintains relationships between sessions of Collecting Processes and of Exporting Processes depends on its implementation. If a session of the Collecting Process is reset and the IPFIX Mediator shuts down the session of the Exporting Process, the Collector would continue in a futile attempt to try to establish the session. And also, if multiple sessions of the Collecting Process are relayed to single session of the Exporting Process, and the IPFIX Mediators shuts down the session of the Exporting Process, other sessions of the Collecting Processes would not be relayed at all. In the following figure, an IPFIX Mediator relays from a session of Collecting Process to a session of Exporting Process. If the session between a Router and a Mediator fails and the IPFIX Mediator shuts down the session between the Collector and the Mediator, the Collector would futilely continue to try to establish the session. .--------. .--------. .---------. |IPFIX | |IPFIX | | | |Router |----X---->|Mediator|----X---->|Collector| | | | | | | '--------' '--------' '---------' Figure C: The case of relaying from a session to a session. Kobayashi, et al. Expires August 24, 2008 [Page 13] Internet-Draft Problem Statement in large NW February 2008 In the following figure, an IPFIX Mediator relays from multiple sessions of Collecting Process to a session of Exporting Process. If one of these sessions between Routers and the Mediator fails and IPFIX Mediator shuts down the session between a Collector and the Mediator, other sessions between the Routers and the Mediator would not be relayed at all. .--------. |IPFIX | |Router#1|----+ | | | '--------' X .--------. | .--------. .---------. |IPFIX | '---->|IPFIX | | | |Router#2|--------->|Mediator|----X---->|Collector| | | +---->| | | | '--------' | '--------' '---------' .--------. | |IPFIX | | |Router#3|----' | | '--------' Figure D: The case of relaying from multiple sessions to a session. Therefore, each session of the Collecting Process and Exporting Process should operate independently. Even if one session is reset, the status of the other sessions is kept. However, if Templates that reset the session of Collecting Processes would not be withdrawn, there is a possibility that assigned Template IDs overlap. The Collector might then shut down IPFIX session, because it identifies the overlapping Template ID as part of an anomalous message. In the case of resetting a session of the Collecting Process, the operation processed by IPFIX Mediator should be defined. Kobayashi, et al. Expires August 24, 2008 [Page 14] Internet-Draft Problem Statement in large NW February 2008 6. Conclusion This document has covered a multitude of problems related to flow- based measurement system in large-scale networks. Section 4 has listed several solutions to cope with huge traffic volumes. These problems can not be solved by just adjusting the sampling rate and/or granularity of Flow Records. The use of IPFIX Mediators, on the other hand, seems to be a useful means for constructing large-scale collection systems. And also, network providers can explore solutions by utilizing advanced features of Exporters and Collectors, but it is difficult to perform an atomic migration of the whole measurement system while the amount of traffic grows. To assist the ability of Exporters and Collectors, it should be noted that there are some IPFIX devices, IPFIX Mediators, for the network providers to select. However, there are open issues related to IPFIX Mediation. o Current load balancing ways for flow-based measurement can still be improved. In integrated networks, which mix MPLS VPN with other tunnel traffic and IPv4/IPv6, these ways would be utilized more. More sophisticated ways could enhance the effectiveness. o Using IPFIX Mediators might lose Observation Point and IPFIX header information, such as the Exporter IP address, Observation Domain ID and the Export Time field. These data should be communicated between Original Exporter and Collector via IPFIX Mediator. o Using IPFIX Mediators might lose data advertised by Option Templates from the Original Exporter, such as the sampling rate and sampling algorithm used. If a Collector is not informed of current sampling rates, traffic information becomes worthless. o IPFIX Mediators are required to manage Transport Sessions, Template IDs, and Observation Domain IDs. Otherwise, anomalous IPFIX messages would be created. Many of these problems stem from the fact that standards regarding IPFIX Mediation are missing. In particular, the minimum set of information which should be communicated between Original Exporter and Collector, interworking between both IPFIX sessions, and the internal components of IPFIX Mediators should be standardized. Kobayashi, et al. Expires August 24, 2008 [Page 15] Internet-Draft Problem Statement in large NW February 2008 7. Security Considerations A flow-based measurement system might lead to privacy violation problems, such as the export of flows to an unexpected address, if the system is not confined to the large-scale network under observation. General security issues of the IPFIX protocol are covered by the security considerations section in [RFC5101]. Security MUST be considered, if different networks exchange the flow information. As the security of the exchange relies mostly on the protocol used, UDP does not seem appropriate for the exchange of information between networks. Kobayashi, et al. Expires August 24, 2008 [Page 16] Internet-Draft Problem Statement in large NW February 2008 8. IANA Considerations This document has no actions for IANA. Kobayashi, et al. Expires August 24, 2008 [Page 17] Internet-Draft Problem Statement in large NW February 2008 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", January 2008. 9.2. Informative References [I-D.dressler-ipfix-aggregation] Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, "IPFIX Aggregation", draft-dressler-ipfix-aggregation-04.txt (work in progress) , November 2007. [I-D.ietf-ipfix-as] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", draft-ietf-ipfix-as-12.txt (work in progress) , June 2007. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export(IPFIX)", October 2004. [TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact and Implications of the Growth in Residential User-to-User Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September 2006. , October 2006. Kobayashi, et al. Expires August 24, 2008 [Page 18] Internet-Draft Problem Statement in large NW February 2008 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 Haruhiko Nishida NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3978 Email: nishida.haruhiko@lab.ntt.co.jp Christoph Sommer University of Erlangen-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27993 Email: christoph.sommer@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~sommer/ Falko Dressler University of Erlangen-Nuremberg 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/~dressler/ Kobayashi, et al. Expires August 24, 2008 [Page 19] Internet-Draft Problem Statement in large NW February 2008 Emile Stephan France Telecom 2 avenue Pierre Marzin Lannion F-22307 France Phone: +33 2 96 05 18 52 Email: emile.stephan@orange-ftgroup.com Kobayashi, et al. Expires August 24, 2008 [Page 20] Internet-Draft Problem Statement in large NW February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kobayashi, et al. Expires August 24, 2008 [Page 21]