--- 1/draft-ietf-mboned-ip-multicast-pm-requirement-00.txt 2011-07-01 11:16:29.000000000 +0200 +++ 2/draft-ietf-mboned-ip-multicast-pm-requirement-01.txt 2011-07-01 11:16:30.000000000 +0200 @@ -1,20 +1,28 @@ Network working group A. Tempia Bonda Internet Draft G. Picciano Intended status: Informational Telecom Italia M. Chen L. Zheng Huawei Technologies Co., Ltd -Expires: July 17, 2011 January 17, 2011 +Expires: January 1, 2012 July 1, 2011 Requirements for IP multicast performance monitoring - draft-ietf-mboned-ip-multicast-pm-requirement-00.txt + draft-ietf-mboned-ip-multicast-pm-requirement-01.txt + +Abstract + + This document describes the requirement for an IP multicast + performance monitoring system for service provider IP multicast + networks. This system enables efficient performance monitoring in + Service Providers' production networks and provides diagnostic + information in case of performance degradation or failure. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. @@ -22,84 +30,75 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 17, 2011. + This Internet-Draft will expire on January 1, 2011. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. -Abstract - - This document describes the requirement for an IP multicast - performance monitoring system for service provider IP multicast - networks. This system enables efficient performance monitoring in - Service Providers' production networks and provides diagnostic - information in case of performance degradation or failure. - Table of Contents - 1. Introduction ................................................ 2 - 2. Conventions used in this document ........................... 4 - 3. Terminologies ............................................... 4 - 4. Functional Requirements ..................................... 6 - 4.1. Topology discovery and monitoring ...................... 6 - 4.2. Performance measurement ................................ 6 - 4.2.1. Loss rate ......................................... 6 - 4.2.2. One-way delay ..................................... 7 - 4.2.3. Jitter ............................................ 7 - 4.2.4. Throughput ........................................ 7 - 4.3. Measurement session management ......................... 8 - 4.3.1. Segment v.s. Path ................................. 8 - 4.3.2. Static v.s. Dynamic configuration ................. 8 - 4.3.3. Proactive v.s. on-demand .......................... 8 - 4.4. Measurement result report .............................. 9 - 4.4.1. Performance reports ............................... 9 - 4.4.2. Exceptional alarms ................................ 9 - 5. Design considerations ...................................... 10 - 5.1. Inline data-plane measurement ......................... 10 - 5.2. Scalability ........................................... 10 - 5.3. Robustness ............................................ 11 - 5.4. Security .............................................. 11 - 5.5. Device flexibility .................................... 11 - 5.6. Extensibility ......................................... 12 - 6. Security Considerations .................................... 12 - 7. IANA Considerations ........................................ 12 - 8. References ................................................. 12 - 8.1. Normative References .................................. 12 - 8.2. Informative References ................................ 12 - 9. Acknowledgments ............................................ 13 + 1. Introduction ................................................. 3 + 2. Conventions used in this document ............................ 4 + 3. Terminologies ................................................ 4 + 4. Functional Requirements ...................................... 6 + 4.1. Topology discovery and monitoring ....................... 6 + 4.2. Performance measurement ................................. 6 + 4.2.1. Loss rate .......................................... 6 + 4.2.2. One-way delay ...................................... 7 + 4.2.3. Jitter ............................................. 7 + 4.2.4. Throughput ......................................... 8 + 4.3. Measurement session management .......................... 8 + 4.3.1. Segment v.s. Path .................................. 8 + 4.3.2. Static v.s. Dynamic configuration .................. 8 + 4.3.3. Proactive v.s. on-demand ........................... 9 + 4.4. Measurement result report ............................... 9 + 4.4.1. Performance reports ................................ 9 + 4.4.2. Exceptional alarms ................................. 9 + 5. Design considerations ....................................... 10 + 5.1. Inline data-plane measurement .......................... 10 + 5.2. Scalability ............................................ 11 + 5.3. Robustness ............................................. 11 + 5.4. Security ............................................... 11 + 5.5. Device flexibility...................................... 11 + 5.6. Extensibility .......................................... 12 + 6. Security Considerations ..................................... 12 + 7. IANA Considerations ......................................... 12 + 8. References .................................................. 12 + 8.1. Normative References ................................... 12 + 8.2. Informative References ................................. 12 + 9. Acknowledgments ............................................. 14 1. Introduction Service providers (SPs) have been leveraging IP multicast to provide revenue-generating services, such as IP television (IPTV), video conferencing, as well as the distribution of stock quotes or news. - These services are usually loss-sensitive or delay-sensitive, and their data packets need to be delivered over a large scale IP network in real-time. Meanwhile, these services demand relatively strict service-level agreements (SLAs). For example, loss rate over 5% is generally considered unacceptable for IPTV delivery. Video conferencing normally demands delays no more than 150 milliseconds. However, the real-time nature of the traffic and the deployment scale of service make it very challenging for IP multicast performance monitoring in a SP's production network. With increasing deployment of multicast service in SP networks, it becomes mandatory to develop @@ -288,37 +287,39 @@ interface of this segment and the time when the same user packet arrives at the ending interface of this segment. The one-way delay metric is essential for real-time interactive applications, such as video/audio conferencing, multiplayer gaming. One-way delay over any segment of a multicast forwarding path SHOULD be able to be measured. The measurement interval MUST be configurable. To get accurate one-way delay measurement results, the two end monitoring nodes of the investigated segments might need to have - clock synchronized. + clock synchronized. The one-way delay metric for packet networks is + described in RFC2679 [13]. 4.2.3. Jitter Jitter over a segment is the variance of one-way delay over this segment during a given interval. The metric is of great importance for real-time streaming and interactive applications, such as IPTV, audio/video conferencing. One-way delay jitter over any segment of a multicast forwarding path SHOULD be able to be measured. The measurement interval MUST be configurable. Same as One-way delay measurement, to get accurate jitter, the clock frequencies at the two end monitoring nodes might need to be synchronized so that the clocks at two systems will proceed at the - same pace. + same pace. The jitter metric for packet networks is described in + RFC2681 [14]. 4.2.4. Throughput Throughput of multicast traffic for a group over a segment is the average number of bytes of user packets of this multicast group transmitted over this segment in unit time during a given interval. The information might be useful for resource management. Throughput of multicast traffic over any segment of a multicast forwarding path MAY be measured. The measurement interval MUST be @@ -422,21 +423,21 @@ account when design the system. 5.1. Inline data-plane measurement Measurement results collected by probing packets might be biased or even totally irrelevant given the facts that (1) probing packets collect sampled results only and might not capture the real statistic characteristics of the monitored user traffic. Experiments have demonstrated that the measurement sampled by the probing packets, such as ping probes, might be incorrect if sampling interval is too - long [10]; (2) probing packets introduce extra load onto the network. + long [1]; (2) probing packets introduce extra load onto the network. In order to improve accuracy, sampling frequency has to be high enough, which in turn increase network overhead and further bias the measurement results; (3) probing packets are usually not in the same multicast group as user packets and might take different forwarding path given that equal cost multi-path routing (ECMP) and link aggregation (LAG) have been widely adopted in SP network. An out-of- band probing packet might take a path totally different from the user packets of the multicast group that it is monitoring. Even if the forwarding path is the same, the intermediate node might apply different queuing and scheduling strategy for the probing packets. As @@ -577,52 +578,54 @@ [11] Sarac, K. and K. Almeroth, "Monitoring IP Multicast in the Internet: Recent Advances and Ongoing Challenges", Journal IEEE Communication Magazine, 2005. [12] Vit Novotny, Dan Komosny, "Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks," icwmc, pp.85, Third International Conference on Wireless and Mobile Communications (ICWMC'07), 2007 + [13] Almes, G., Kalidindi,S. and M. Zekauskas, "A One-way Delay + Metric for IPPM", RFC 2679, September 1999 + + [14] Almes, G., Kalidindi,S. and M. Zekauskas, "A Round-trip Delay + Metric for IPPM", RFC 2681, September 1999. + 9. Acknowledgments The authors would like to thank Wei Cao, Xinchun Guo, and Hui Liu for their helpful comments and discussions. - This document was prepared using 2-Word-v2.0.template.dot. - Authors' Addresses Alberto Tempia Bonda Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy Email: alberto.tempiabonda@telecomitalia.it Giovanni Picciano Telecom Italia Via Di Val Cannuta 250 Roma 00166 Italy Email: giovanni.picciano@telecomitalia.it Mach(Guoyi) Chen - Huawei Technologies Co. Ltd. - Huawei Building, No.3 Xinxi Road, - Hai-Dian District, - Beijing, 100085 + Huawei Technologies Co., Ltd + No. 3 Xinxi Road, Shang-di, Hai-dian District + Beijing 100085 China - EMail: mach@huawei.com + Email: mach@huawei.com Lianshu Zheng - Huawei Technology Co. Ltd. - Huawei Building, No.3 Xinxi Road, - Hai-Dian District, - Beijing, 100085 + Huawei Technologies Co., Ltd + No. 3 Xinxi Road, Shang-di, Hai-dian District + Beijing 100085 China Email: verozheng@huawei.com