IPFIX Working Group A. Kobayashi Internet-Draft H. Nishida Intended status: Informational NTT PF Lab. Expires: August 28, 2008 February 25, 2008 Multicast Traffic Measurement with IPFIX/PSAMP draft-kobayashi-ipfix-multicast-measure-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 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kobayashi & Nishida Expires August 28, 2008 [Page 1] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 Abstract The demand for streaming services is increasing because of the growing number of broadband users. In particular, multicast services might become core network services, and additional demand is expected. On the other hand, multicast operation is quite complex, and there are strict network quality requirements about packet loss and delay. A measurement system using IPFIX/PSAMP helps to monitor multicast traffic behavior carefully. However, some problems with IPFIX/PSAMP still remain when network operators try to introduce the measurement system. This document describes issues that the multicast traffic measurement system might encounter. The results are intended to be used to define multicast handling by IPFIX/PSAMP metering devices more clearly. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Existing Measurement Methods for Multicast . . . . . . . . 4 2.2. Monitoring Multicast Topology . . . . . . . . . . . . . . 5 2.3. Monitoring Multicast Service Quality . . . . . . . . . . . 5 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Kobayashi & Nishida Expires August 28, 2008 [Page 2] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 1. Introduction IP multicast is a useful service for offering video streaming to a lot of users, by consuming minimal network resources. Increasing the number of broadband users leads to heavy demand for multicast services, such as IPTV. On the other hand, multicast traffic needs to be monitored from a different perspective than that of IP unicast and managed in more complex situations. Therefore, the IPFIX/PSAMP technique could play a great role to help resolve these problems and provide easy operation. IPFIX/PSAMP enables measuring multicast service quality, multicast path tree, and how many subscribers watch IPTV channels. For example, its measurement system visualizes the multicast path tree. The color of these path trees indicates network quality conditions, and the girth of the path tree indicates the number of customers watching each IPTV channel. Network operators can grasp the condition of multicast services, and immediately answer a customer's network condition when the customer asks. The IPFIX/PSAMP measurement system might encounter several problems. A series of IPFIX documents make little mention of methods for exporting multicast flow. IPFIX requirement document [RFC3917] describes a method of handling about multicast flows containing packets replicated to multiple output interfaces. This method complicates the implementation of IPFIX/PSAMP Collectors. In this document, we describe unresolved problems related to multicast measurement methods. Kobayashi & Nishida Expires August 28, 2008 [Page 3] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 2. Problem Statement 2.1. Existing Measurement Methods for Multicast Network operators already use several tools for aiding network management, troubleshooting, and diagnosis for multicasts, as follows. o Multicast ping and traceroute Network operators try to investigate failure points between sender and receivers by using multicast ping and multicast traceroute when network failure occurs or customers ask about the multicast service condition. Multicast ping can collect responses from end hosts, but that is not actual traffic, and investigating failure points is difficult. In addition, multicast traceroute can show the multicast path, but that path is incomplete because the path indicates the reverse path from downstream to upstream. o Multicast routing MIB To ensure the reach of multicast traffic for subscribers, network operators need to manage subscribers of multicast services, and figure out the multicast topologies by multicast routing entries based on the pair of source address and multicast group address using Multicast Routing MIB in [RFC2932]. Regrettably IPv4 alone has not become a popular solution. o Packet mirroring Furthermore, to confirm service quality, network operators make use of packet mirroring as the last resort. To confirm service quality, network operators need to examine carefully mirrored multicast packets, and network operators check if there are the lost packets or disordered packets. To monitor multicast service quality, using mirroring packets is the only solution at this time. This solution cannot be introduced into the whole network domain. It is a costly alternative. These existing multicast tools and solutions work well within some network domain scale. However, existing solutions cost a great deal and a lot of effort is required to introduce multicast solutions to service provider networks. In addition, actual multicast traffic behavior that passes through networks can not be monitored constantly between the receiver and sender. Therefore, IPFIX/PSAMP techniques enable passive measurement of actual multicast traffic and would be a cost-effective method. In particular, multicast topology and service quality can be demonstrated by IPFIX/PSAMP techniques. We describe these methods and their related issues in the following sections. Kobayashi & Nishida Expires August 28, 2008 [Page 4] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 2.2. Monitoring Multicast Topology To monitor the multicast topology, Flow Records with input interface indexes and output interface indexes should be gathered from all multicast routers. However, the IPFIX requirement in [RFC3917] describes that the Metering Process should be able to maintain discrete Flow Records per different output interface. Even if the Observation Point is located in an input interface, exporting multiple Flow Records on the basis of the output interface is more complicated. Implicitly, an output interface is configured to be a Flow Key. This is similar to the situation where all interfaces are set as Observation Points in both directions. If all interfaces are set as Observation Points in both directions, then sampling instances will work independently from both ingress and other egress interfaces. In this case, this method may not work properly to get topology information. Because there is no packet sampled during some period on each side. Though this method is one of several solutions, from the operator's point of view, preferably, the number of Observation Points is to be set to a minimum. On the Collector side, excluding Flow Records with an output interface to count the number of packets and bytes at an input interface from several Flow Records is an extra function. In that case, both Flow Records should clearly contain the Direction field. On the Exporter side, the Exporter needs to equip additional cache memory to maintain replicated Flow Records. In addition, exporting replicated Flow Records might overload the Exporter and Collector. In particular, replicated Flow Records are exported all at once when the metering process detects an Active Timeout. This issue could become a serious problem at access routers in which thousands of subscribers have joined. 2.3. Monitoring Multicast Service Quality The measurement of packet loss and delay is vital to monitor multicast service quality. To that end, network operators make use of the PSAMP technique, which can filter a specified multicast group address and export each packet with "ipHeaderPacketSection", "ipPayloadPacketSection", and "observationTime" fields. On the Collector side, network quality, such as packet loss, delay, disorder, and arrival interval time, can be measured for every multicast group address by using the RTP header information. That is the best suite solution to determine multicast service quality. However, service provider networks have multiple multicast group addresses. Therefore, these addresses should be filtered by Field Match Filtering in [I-D.ietf-psamp-sample-tech]. However, Multiple Kobayashi & Nishida Expires August 28, 2008 [Page 5] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 multicast addresses cannot be set in one SelectionSequence described in [I-D.ietf-psamp-protocol] because PSAMP cannot be allowed to performed the "OR" operation in Field Match Filtering. To monitor several group addresses, Exporters need to create dedicated metering processes, which seems to be an inefficient solution. Generally, filtering techniques have been used in network devices as access lists. The filtering schemes in PSAMP should harmonize with general access list schemes. Network operators might be confused by the different perspective. Kobayashi & Nishida Expires August 28, 2008 [Page 6] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 3. Conclusion This document has covered the following problems related to multicast measurement systems with IPFIX/PSAMP. o Maintaining and exporting replicated multicast Flow Records would overload Exporters and Collectors. Increasing the number of multicast subscribers, it might become a serious problem. o The method of filtering by the PSAMP technique is a different scheme from the general access list scheme. When network operators apply the filter for multiple multicast group addresses, dedicated metering processes according to each multicast group address need to be created. That seems to be inefficient. To cope with these issues, there should be no major problems to confront. In consideration of the situation of existing operation methods, IPFIX/PSAMP would have a great role in multicast measurement. In addition, an efficient measurement method using IPFIX/PSAMP is becoming more and more necessary for network operators along with the popularization of IPTV. Therefore, IPFIX documents should describe a method of handling multicast flow more clearly so that the method can be introduced into several networks. Kobayashi & Nishida Expires August 28, 2008 [Page 7] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 4. Security Considerations The method described in this document uses the IPFIX protocol. Security considerations about flow information are described in [RFC5101]. Kobayashi & Nishida Expires August 28, 2008 [Page 8] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 5. IANA Considerations This document has no actions for IANA. Kobayashi & Nishida Expires August 28, 2008 [Page 9] Internet-Draft Multicast Measurement with IPFIX/PSAMP February 2008 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", October 2000. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export(IPFIX)", October 2004. [RFC5101] Claise, B., "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information", January 2008. 6.2. Informative References [I-D.ietf-psamp-protocol] Claise, B., "Packet Sampling (PSAMP) Protocol Specifications", draft-ietf-psamp-protocol-09.txt (work in progress) , December 2007. [I-D.ietf-psamp-sample-tech] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "", draft-ietf-psamp-sample-tech-10.txt (work in progress) , June 2007. Kobayashi & Nishida Expires August 28, 2008 [Page 10] Internet-Draft Multicast Measurement with IPFIX/PSAMP 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 Kobayashi & Nishida Expires August 28, 2008 [Page 11] Internet-Draft Multicast Measurement with IPFIX/PSAMP 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 & Nishida Expires August 28, 2008 [Page 12]