Internet Engineering Task Force MBONED Working Group INTERNET-DRAFT Kevin Almeroth draft-ietf-mboned-mrm-use-00.txt UCSB Expires August 1999 Liming Wei cisco Systems, Inc February 26, 1999 Justification for and use of the Multicast Routing Monitor (MRM) Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document motivates the need for the Multicast Routing Monitor (MRM) [MRM] protocol by describing the niche that exists for a router-based multicast management protocol. Using the "sufficient and necessary" argument, we suggest that existing protocols and techniques lack important management functionality. This document briefly describes the methodology used by MRM, justifies the existence of MRM, and describes some of the scenarios in which MRM will be of value. 1. Introduction The Multicast Routing Monitor (MRM) protocol has been designed to assist in the detection and isolation of network faults related to the delivery of multicast traffic[MRM99]. In particular, management functions offered by MRM are specifically designed to monitor routing operation, and assist in the investigation of routing anomalies and connectivity problems. MRM has been designed with consideration for the other types of multicast management protocols and tools that are available. As Almeroth, Wei [Page 1]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 we will show, even though there are a wide variety of tools available today, there is a need for a router-based monitoring protocol. The justification for MRM as a new protocol has followed the ``necessary and sufficient'' premise. MRM is being developed because it is necessary when comparing its functions to those offered by alternatives like the Real Time Control Protocol (RTCP) [RTP] and the Simple Network Management Protocol (SNMP) [SNMPV1,SNMPV2]. Furthermore, MRM is being developed because it is sufficient in providing the functions needed by its target class of applications. Using this reasoning, MRM will offered functions and provide multicast traffic management that no other protocols currently offer. 2. Overview of MRM MRM is a protocol intended to be implemented in both routers and end stations. The operation of MRM is based on communication and coordination between three types of network entities. * MRM Manager: The MRM manager provides an interface enabling a user to configure and execute tests, and then collect and present results. The MRM manager communicates with MRM testers who are instructed to source and/or sink multicast traffic. The MRM manager, through beacon messages, also maintains and modifies the set of MRM testers. * Test Sender (TS): A test sender is basically responsible for sourcing multicast traffic. TSs will receive authenticated requests from the MRM manager and will send a specified number of multicast packets to a specified multicast address with a specified inter-transmission time between packets. * Test Receiver (TR): Based on instructions from an MRM manager, a test receiver is expected to either explicitly join a multicast group or simply monitor traffic on a specified group address. Based on thresholds specified by the MRM manager, a TR will report faults. Additionally, the MRM manager may request TR reports regardless of whether any thresholds were violated. One of the keys to scalability is ensuring that a large number of TRs don't overwhelm the MRM manager with traffic. Scalability is handled using a combination of techniques including report suppression and aggregation. As the MRM protocol specification indicates about itself, ``it only specifies the types of information a MRM manager can obtain, and the protocol used to acquire such information. How an MRM manager processes or presents the diagnostic information is an implementation issue.'' These functions are expected to be provided using companion management tools. Furthermore, the MRM protocol specification does not fully describe the scenarios in which MRM is expected to be useful. Such functions and scenarios are described in Section 4 of this document. Almeroth, Wei [Page 2]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 3. Justification MRM provides a set of functions not provided by any of the commonly used MBone debugging protocols and tools. Most of the tools used in the MBone today fall into one of three categories: (1) SNMP-based tools like Mview [MVIEW] or Mstat [MSTAT]; (2) RTCP-based tools like Mhealth [MHEALTH], RTPmon [RTPMON], or MultiMON [MULTIMON]; or (3) multicast route tracing tools like Mtrace [MTRACE1,MTRACE2]. MRM, in addition to being an independent management tool, can be used in conjunction with these other tools to provide a richer set of management functions. Some of the reasons why the above protocols or tools fail are discussed in the following paragraphs. * SNMP: SNMP provides a mechanism to poll devices for information or to have alarms generated when certain events occur. The problem with SNMP is that a wide ranging failure could potentially overwhelm a management station. For example, consider a scenario in which SNMP agents in a particular multicast tree are configured to generate an alarm if the packet loss exceeds a certain level. Then consider the implosion that would occur if a link close to the root becomes congested, and a majority of group members generated alarms. This scenario demonstrates the basic drawbacks of SNMP: a general lack of scalability especially when considering that large number of devices/hosts that may be involved in a multicast group. Scalability arguments do not preclude the use of SNMP, but a manager using SNMP to manage multicast would have to be extremely careful in deciding how to configure the network. In fact, properly configuring network devices to provide sufficient management information while avoiding management-induced congestion or implosion may be prohibitive in most networks. * RTCP: RTCP has a much more scalable feedback mechanism but it has its own deficiencies. The scalability of RTCP is based on a random wait time chosen from an interval calculated by each group member and based on an estimate of the overall group size. The larger the group, the larger the wait interval, and the longer the average inter-packet time between RTCP feedback messages. The goal of the RTCP feedback mechanism to is consume bandwidth equal to 5% of the data traffic rate. While this algorithm seems reasonable it can be problematic as a tool to management multicast traffic. Some reasons include: o RTCP feedback is multicast to all group members, and given that receivers will have heterogeneous bandwidth capabilities, even scalable feedback has the potential to overwhelm some receivers. Almeroth, Wei [Page 3]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 o In many management applications there is no need for feedback data to be transmitted to all group members. And if privacy is an issue, the group-wide delivery of RTCP is even less desirable. o RTCP feedback provides only a single, end-to-end loss and jitter value. More generally, RTCP contains only a very small amount of information useful for debugging purposes. MRM is designed to include a broader range of information, including packet duplication statistics, and also to be extensible. While some of the problems with RTCP are being addressed by redefining the standard to allow more flexibility in the use of RTCP [RTPNEW], these efforts do not solve all of the problems. In particular, the most critical deficiency of RTCP is a lack of detailed routing information. In particular, when trying to isolate routing faults, the end-to-end style feedback provided by RTCP is unlikely to have sufficient granularity. To address this problem, some RTCP-based tools are used in combination with other tools. For example, RTPmon and mtrace are commonly used together. However, the major drawback of this solution is that it fails to provide the sort of traffic origination and flexible group membership services offered by MRM. * Mtrace: Mtrace is a tool designed to provide hop-by-hop path information for a specific source and destination. It is a useful tool for figuring out a multicast path and round trip information. For a specific group, mtrace will also tell a user hop-by-hop packet loss. Coupled with RTCP feedback, mtrace can be used to monitor many of the relevant factors for an active source and group including per-receiver loss, hop-by-hop loss, tree topology, jitter, and round trip time. Several tools in development, including Mhealth, provide a graphical real-time display of group statistics. However, mtrace (coupled with other tools) only provides information about active groups. Attempting to do fault detection, or more specifically, fault pre-detection, is nearly impossible. The common paradigm today is to gather a set of willing participants who then join a ``debugging'' session. Further complicating the problem is that sometimes, starting an MBone tool in a remote location to receive and transmit RTCP reports is not possible. One solution to this problem is a ``dumb'', non-GUI tool that simply receives and responds to an RTP stream. While tools like this have been discussed, but none are widely available, and even if they were, attempting to rapidly configure and change group membership would be laborious at best. MRM is designed with the specific purpose of facilitating on-the-fly, adhoc test multicast senders and receivers to test a variety of multicast group configurations. Almeroth, Wei [Page 4]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 4. Scenarios for Use of MRM MRM is designed to provide automated fault detection and isolation services for multicast traffic. In order to support these services with any kind of automation, MRM must be both flexible and scalable. MRM scalability implies the ability detect faults without raising so many alarms that additional problems are caused from the delivery of alarm messages. One problem, in particular, is response implosion at the MRM manager. MRM flexibility implies the ability to isolate faults by sourcing traffic from anywhere in the network and collecting statistics from any node or subset of nodes. In addition to basic fault detection and isolation, MRM is intended to provide more advanced functions. These extended functions include: * Fault logging and real-time (passive) monitoring functions. * Pro-active test (fault isolation) include service provisioning and impact analysis. The remainder of this section is dedicated to the description of scenarios in which MRM functions are expected to be used. * Pre-Event Testing: One of the best examples of this type of scenario is the MBone delivery of two audio/video channels from the IETF meetings held three times a year all over the world. Preceding the week of meetings for each IETF, staff members install a terminal room and establish network connectivity including multicast capability. In some cases, setup activities occur weeks, days, or hours before the first meeting Monday morning. Verifying that multicast routing is working both into and out of the IETF meeting rooms can be a challenge. Verification is especially challenging because the IETF meetings have a world-wide audience. Ensuring that multicast is working at even a small number of remote sites is difficult. One problem that sometimes occurs is that the MBone equipment, including cameras and workstations, may not be available when the network is first turned on. In these cases, there are no multicast-capable sources or receivers inside the IETF network. MRM would alleviate this problem by allowing testing of multicast in both directions. Furthermore, MRM would also allow someone not yet on site to test multicast connectivity. Relatively extensive testing can be performed by choosing a set of Test Receivers representative of the world-wide distribution of actual IETF participants. MRM would allow the IETF staff and the ISP to observe where major network bottlenecks are occurring. In some cases, early discovery of problems could lead to fixes in time for the event. Almeroth, Wei [Page 5]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 These techniques, used for pre-event testing at ``nomadic events'', would also be appropriate for estimating the quality of transmissions events in ``non-nomadic'' networks. Instead of the IETF or an academic conference, an MRM manager might want to estimate the loss, delay, and jitter for a frequently scheduled event like an MBone lecture or company event. Instead of waiting until the event starts and using a tool like RTPmon, an MRM manager can set up a test session any time before the session starts, and evaluate the quality to most, if not all of the critical company locations. In the MBone today, if a transmitter wants to perform this kind of testing, the transmitter will, out-of-band, have to ask several friends to join a test session and then send a multicast stream and monitor RTCP reports. Obviously, this method is not very compelling. * Classic Fault Isolation: A second scenario that MRM is designed to assist a network manager in is classic fault isolation. Like unicast routing, multicast routing problems can be very difficult to debug. And unlike unicast routing, the additional complexities of providing efficient, one-to-many delivery can introduce additional bugs that are difficult to find. To date, a significant number of strategies, tools, and techniques have been developed, built, and proposed [MDH]. However, these attempts generally require a significant level of multicast routing expertise and experience, characteristics not always found among NOC personnel. As a result, MRM is designed to offer a layer of abstraction between multicast route management and the intricacies of multicast routing. MRM is also designed not to be completely independent of the strategies, tools, and techniques already in use today. MRM and existing tools can work in concert to isolate multicast routing problems. MRM's design offers some important flexibility in isolating multicast routing faults. In particular, the ability to specify a transmission rate allows a manager to closely inspect single, infrequently transmitted packets. Also, the ability to easily add and remove members from the group of Test Receivers allows a manager to quickly and efficiently affect the topology of the multicast tree. * Session Monitoring: The scenarios discussed so far followed logically, from verifying multicast connectivity to isolating any potential faults. The next key scenario is monitoring of existing, active sessions. Such groups will have a well-known multicast address, and might be exchanging group membership information via RTCP reports or some other out-of-band mechanism. If the group is small, and feedback from each receiver is Almeroth, Wei [Page 6]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 important, the set of test receivers can be configured to send reports to the MRM manager via unicast. If the group is large and complete feedback is not necessary, the set of test receivers can be frequently adjusted to represent some statistical sampling of the group. The ability to send statistical reports via unicast helps to improve the scalability of session monitoring by not overwhelming all receivers with all reports. Finally, if the group is using multicast tools that do not use RTCP and use no real-time signaling, generation of a real-time list of group members may be difficult to create. Other techniques will have to be used. One network-layer approach might be to use SNMP information to find the set of links in the multicast tree. A more simple approach might depend on other available information like the fact that most users start the multicast tool via a WWW page. In this case, HTTP server logs can be used to estimate group membership. * Fault Logging: In the case when session monitoring identifies the existence of a fault, a range of fault logging functions may be required. At one extreme, the MRM manager may simply need to be alerted when faults occur so that appropriate investigative measures can be taken. At the other extreme, service contracts may depend on the provision of service with certain guarantees. Any outages will need to be closely tracked. These two extremes again demonstrate the need for MRM to be flexible. In particular, when faults need to be closely monitored and logged, a wide-scale outage may itself cause a heavy load on the network. While identifying the exact load capable of being supported by a distressed network is beyond the scope of MRM, MRM does and will support scalability and aggregation functions. 8. Security Security issues are discussed in the MRM protocol description [MRM]. Almeroth, Wei [Page 7]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 9. Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106-5110 USA almeroth@cs.ucsb.edu Liming Wei cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA lwei@cisco.com 10. References [MRM] L. Wei, and D. Farinacci, "Multicast Routing Monitor (MRM)", IETF Internet-Draft, draft-ietf-mboned-mrm-*.txt, February 1999. [RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", IETF RFC 1889, January 1996. [SNMPV1] J. Case, M. Fedor, M. Schoffstall, and J. Davin, "Simple Network Management Protocol", IETF RFC 1157, May 1990. [SNMPV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", IETF RFC 1905, January 1996. [MVIEW ] D. Thaler, "Mview Tool", http://www.merit.edu/~mbone/mviewdoc/Welcome.html. [MSTAT] B. Fenner, et al., "Mstat", Available as part of mrouted at ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/. [MHEALTH] D. Makofske, and K. Almeroth, "Mhealth -- Real-Time Multicast Tree Health Monitoring Tool", http://imj.ucsb.edu/mhealth/, August 1998. [RTPMON] A. Swan, and D. Bacher, "RTPmon", ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/, January 1997. Almeroth, Wei [Page 8]
INTERNET-DRAFT draft-ietf-mboned-mrm-use-00.txt February 1999 [MULTIMON] J. Robinson, and J. Stewart, "MultiMON 2.0 -- Multicast Network Monitor", http://www.merci.crc.ca/mbone/MultiMON/, August 1998. [MTRACE1] B. Fenner, et al., "Multicast Traceroute (mtrace) 5.2", ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ September 1998. [MTRACE2] B. Fenner, and S. Casner, "A `traceroute' Facility for IP Multicast", IETF Internet-Draft, draft-ietf-idmr-traceroute-ipm-*.txt, November 1995. [RTPNEW] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", IETF Internet-Draft, draft-ietf-avt-rtp-new-*.txt", November 1998. [MDH] D. Thaler, and B. Aboba, "Multicast Debugging Handbook", IETF Internet-Draft, draft-ietf-mboned-mdh-*.txt, October 1998. Almeroth, Wei [Page 9]
