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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/