idnits 2.17.1 draft-ietf-mboned-mrm-use-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MRM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 1999) is 9191 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MRM99' is mentioned on line 45, but not defined == Missing Reference: 'MVIEW' is mentioned on line 108, but not defined -- No information found for draft-ietf-mboned-mrm- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MRM' ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. 'SNMPV1') ** Obsolete normative reference: RFC 1905 (ref. 'SNMPV2') (Obsoleted by RFC 3416) -- Possible downref: Non-RFC (?) normative reference: ref. 'MSTAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'MHEALTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'RTPMON' -- Possible downref: Non-RFC (?) normative reference: ref. 'MULTIMON' -- Possible downref: Non-RFC (?) normative reference: ref. 'MTRACE1' -- No information found for draft-ietf-idmr-traceroute-ipm- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MTRACE2' -- No information found for draft-ietf-avt-rtp-new- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RTPNEW' -- No information found for draft-ietf-mboned-mdh- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MDH' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MBONED Working Group 2 INTERNET-DRAFT Kevin Almeroth 3 draft-ietf-mboned-mrm-use-00.txt UCSB 4 Expires August 1999 Liming Wei 5 cisco Systems, Inc 6 February 26, 1999 8 Justification for and use of the 9 Multicast Routing Monitor (MRM) Protocol 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document motivates the need for the Multicast Routing Monitor 33 (MRM) [MRM] protocol by describing the niche that exists for a 34 router-based multicast management protocol. Using the "sufficient 35 and necessary" argument, we suggest that existing protocols and 36 techniques lack important management functionality. This document 37 briefly describes the methodology used by MRM, justifies the 38 existence of MRM, and describes some of the scenarios in which MRM 39 will be of value. 41 1. Introduction 43 The Multicast Routing Monitor (MRM) protocol has been designed to 44 assist in the detection and isolation of network faults related to 45 the delivery of multicast traffic[MRM99]. In particular, management 46 functions offered by MRM are specifically designed to monitor routing 47 operation, and assist in the investigation of routing anomalies and 48 connectivity problems. 50 MRM has been designed with consideration for the other types of 51 multicast management protocols and tools that are available. As 52 we will show, even though there are a wide variety of tools 53 available today, there is a need for a router-based monitoring 54 protocol. The justification for MRM as a new protocol has followed 55 the ``necessary and sufficient'' premise. MRM is being developed 56 because it is necessary when comparing its functions to those 57 offered by alternatives like the Real Time Control Protocol (RTCP) [RTP] 58 and the Simple Network Management Protocol (SNMP) [SNMPV1,SNMPV2]. 60 Furthermore, MRM is being developed because it is sufficient in 61 providing the functions needed by its target class of applications. 62 Using this reasoning, MRM will offered functions and provide multicast 63 traffic management that no other protocols currently offer. 64 2. Overview of MRM 66 MRM is a protocol intended to be implemented in both routers and 67 end stations. The operation of MRM is based on communication and 68 coordination between three types of network entities. 70 * MRM Manager: The MRM manager provides an interface enabling 71 a user to configure and execute tests, and then collect and 72 present results. The MRM manager communicates with MRM testers 73 who are instructed to source and/or sink multicast traffic. 74 The MRM manager, through beacon messages, also maintains and 75 modifies the set of MRM testers. 77 * Test Sender (TS): A test sender is basically responsible 78 for sourcing multicast traffic. TSs will receive authenticated 79 requests from the MRM manager and will send a specified number 80 of multicast packets to a specified multicast address with a 81 specified inter-transmission time between packets. 83 * Test Receiver (TR): Based on instructions from an MRM manager, 84 a test receiver is expected to either explicitly join a 85 multicast group or simply monitor traffic on a specified group 86 address. Based on thresholds specified by the MRM manager, a 87 TR will report faults. Additionally, the MRM manager may 88 request TR reports regardless of whether any thresholds were 89 violated. One of the keys to scalability is ensuring that a 90 large number of TRs don't overwhelm the MRM manager with 91 traffic. Scalability is handled using a combination of 92 techniques including report suppression and aggregation. 94 As the MRM protocol specification indicates about itself, ``it only 95 specifies the types of information a MRM manager can obtain, and the 96 protocol used to acquire such information. How an MRM manager processes 97 or presents the diagnostic information is an implementation issue.'' 98 These functions are expected to be provided using companion management 99 tools. Furthermore, the MRM protocol specification does not fully 100 describe the scenarios in which MRM is expected to be useful. Such 101 functions and scenarios are described in Section 4 of this document. 103 3. Justification 105 MRM provides a set of functions not provided by any of the commonly 106 used MBone debugging protocols and tools. Most of the tools used 107 in the MBone today fall into one of three categories: (1) SNMP-based 108 tools like Mview [MVIEW] or Mstat [MSTAT]; (2) RTCP-based tools like 109 Mhealth [MHEALTH], RTPmon [RTPMON], or MultiMON [MULTIMON]; or 110 (3) multicast route tracing tools like Mtrace [MTRACE1,MTRACE2]. 111 MRM, in addition to being an independent management tool, can be 112 used in conjunction with these other tools to provide a richer set 113 of management functions. Some of the reasons why the above protocols 114 or tools fail are discussed in the following paragraphs. 116 * SNMP: SNMP provides a mechanism to poll devices for 117 information or to have alarms generated when certain events 118 occur. The problem with SNMP is that a wide ranging failure 119 could potentially overwhelm a management station. For example, 120 consider a scenario in which SNMP agents in a particular 121 multicast tree are configured to generate an alarm if the packet 122 loss exceeds a certain level. Then consider the implosion that 123 would occur if a link close to the root becomes congested, and 124 a majority of group members generated alarms. This scenario 125 demonstrates the basic drawbacks of SNMP: a general lack of 126 scalability especially when considering that large number of 127 devices/hosts that may be involved in a multicast group. 128 Scalability arguments do not preclude the use of SNMP, but a 129 manager using SNMP to manage multicast would have to be extremely 130 careful in deciding how to configure the network. In fact, 131 properly configuring network devices to provide sufficient 132 management information while avoiding management-induced congestion 133 or implosion may be prohibitive in most networks. 135 * RTCP: RTCP has a much more scalable feedback mechanism but it 136 has its own deficiencies. The scalability of RTCP is based on 137 a random wait time chosen from an interval calculated by each 138 group member and based on an estimate of the overall group size. 139 The larger the group, the larger the wait interval, and the longer 140 the average inter-packet time between RTCP feedback messages. 141 The goal of the RTCP feedback mechanism to is consume bandwidth 142 equal to 5% of the data traffic rate. While this algorithm seems 143 reasonable it can be problematic as a tool to management multicast 144 traffic. Some reasons include: 146 o RTCP feedback is multicast to all group members, and given 147 that receivers will have heterogeneous bandwidth capabilities, 148 even scalable feedback has the potential to overwhelm some 149 receivers. 151 o In many management applications there is no need for feedback 152 data to be transmitted to all group members. And if privacy 153 is an issue, the group-wide delivery of RTCP is even less 154 desirable. 156 o RTCP feedback provides only a single, end-to-end loss and 157 jitter value. More generally, RTCP contains only a very small 158 amount of information useful for debugging purposes. MRM is 159 designed to include a broader range of information, including 160 packet duplication statistics, and also to be extensible. 162 While some of the problems with RTCP are being addressed by 163 redefining the standard to allow more flexibility in the use of 164 RTCP [RTPNEW], these efforts do not solve all of the problems. 165 In particular, the most critical deficiency of RTCP is a lack of 166 detailed routing information. In particular, when trying to 167 isolate routing faults, the end-to-end style feedback provided 168 by RTCP is unlikely to have sufficient granularity. To address 169 this problem, some RTCP-based tools are used in combination with 170 other tools. For example, RTPmon and mtrace are commonly used 171 together. However, the major drawback of this solution is that 172 it fails to provide the sort of traffic origination and flexible 173 group membership services offered by MRM. 175 * Mtrace: Mtrace is a tool designed to provide hop-by-hop path 176 information for a specific source and destination. It is a 177 useful tool for figuring out a multicast path and round trip 178 information. For a specific group, mtrace will also tell a user 179 hop-by-hop packet loss. Coupled with RTCP feedback, mtrace can 180 be used to monitor many of the relevant factors for an active 181 source and group including per-receiver loss, hop-by-hop loss, 182 tree topology, jitter, and round trip time. Several tools in 183 development, including Mhealth, provide a graphical real-time 184 display of group statistics. However, mtrace (coupled with other 185 tools) only provides information about active groups. Attempting 186 to do fault detection, or more specifically, fault pre-detection, 187 is nearly impossible. The common paradigm today is to gather a 188 set of willing participants who then join a ``debugging'' session. 189 Further complicating the problem is that sometimes, starting an 190 MBone tool in a remote location to receive and transmit RTCP 191 reports is not possible. One solution to this problem is a 192 ``dumb'', non-GUI tool that simply receives and responds to an 193 RTP stream. While tools like this have been discussed, but none 194 are widely available, and even if they were, attempting to rapidly 195 configure and change group membership would be laborious at best. 196 MRM is designed with the specific purpose of facilitating 197 on-the-fly, adhoc test multicast senders and receivers to test 198 a variety of multicast group configurations. 200 4. Scenarios for Use of MRM 202 MRM is designed to provide automated fault detection and isolation 203 services for multicast traffic. In order to support these services 204 with any kind of automation, MRM must be both flexible and scalable. 205 MRM scalability implies the ability detect faults without raising 206 so many alarms that additional problems are caused from the delivery 207 of alarm messages. One problem, in particular, is response implosion 208 at the MRM manager. MRM flexibility implies the ability to isolate 209 faults by sourcing traffic from anywhere in the network and collecting 210 statistics from any node or subset of nodes. In addition to basic 211 fault detection and isolation, MRM is intended to provide more advanced 212 functions. These extended functions include: 214 * Fault logging and real-time (passive) monitoring functions. 216 * Pro-active test (fault isolation) include service provisioning 217 and impact analysis. 219 The remainder of this section is dedicated to the description of 220 scenarios in which MRM functions are expected to be used. 222 * Pre-Event Testing: One of the best examples of this type of 223 scenario is the MBone delivery of two audio/video channels from 224 the IETF meetings held three times a year all over the world. 225 Preceding the week of meetings for each IETF, staff members 226 install a terminal room and establish network connectivity 227 including multicast capability. In some cases, setup activities 228 occur weeks, days, or hours before the first meeting Monday 229 morning. Verifying that multicast routing is working both into 230 and out of the IETF meeting rooms can be a challenge. 231 Verification is especially challenging because the IETF meetings 232 have a world-wide audience. Ensuring that multicast is working 233 at even a small number of remote sites is difficult. One 234 problem that sometimes occurs is that the MBone equipment, 235 including cameras and workstations, may not be available when 236 the network is first turned on. In these cases, there are no 237 multicast-capable sources or receivers inside the IETF network. 238 MRM would alleviate this problem by allowing testing of multicast 239 in both directions. Furthermore, MRM would also allow someone not 240 yet on site to test multicast connectivity. Relatively extensive 241 testing can be performed by choosing a set of Test Receivers 242 representative of the world-wide distribution of actual IETF 243 participants. MRM would allow the IETF staff and the ISP to 244 observe where major network bottlenecks are occurring. In some 245 cases, early discovery of problems could lead to fixes in time 246 for the event. 248 These techniques, used for pre-event testing at ``nomadic 249 events'', would also be appropriate for estimating the quality 250 of transmissions events in ``non-nomadic'' networks. Instead of 251 the IETF or an academic conference, an MRM manager might want to 252 estimate the loss, delay, and jitter for a frequently scheduled 253 event like an MBone lecture or company event. Instead of waiting 254 until the event starts and using a tool like RTPmon, an MRM 255 manager can set up a test session any time before the session 256 starts, and evaluate the quality to most, if not all of the 257 critical company locations. In the MBone today, if a transmitter 258 wants to perform this kind of testing, the transmitter will, 259 out-of-band, have to ask several friends to join a test session 260 and then send a multicast stream and monitor RTCP reports. 261 Obviously, this method is not very compelling. 263 * Classic Fault Isolation: A second scenario that MRM is designed 264 to assist a network manager in is classic fault isolation. Like 265 unicast routing, multicast routing problems can be very difficult 266 to debug. And unlike unicast routing, the additional 267 complexities of providing efficient, one-to-many delivery can 268 introduce additional bugs that are difficult to find. To date, 269 a significant number of strategies, tools, and techniques have 270 been developed, built, and proposed [MDH]. However, these 271 attempts generally require a significant level of multicast 272 routing expertise and experience, characteristics not always 273 found among NOC personnel. As a result, MRM is designed to offer 274 a layer of abstraction between multicast route management and the 275 intricacies of multicast routing. MRM is also designed not to be 276 completely independent of the strategies, tools, and techniques 277 already in use today. MRM and existing tools can work in concert 278 to isolate multicast routing problems. 280 MRM's design offers some important flexibility in isolating 281 multicast routing faults. In particular, the ability to specify 282 a transmission rate allows a manager to closely inspect single, 283 infrequently transmitted packets. Also, the ability to easily 284 add and remove members from the group of Test Receivers allows a 285 manager to quickly and efficiently affect the topology of the 286 multicast tree. 288 * Session Monitoring: The scenarios discussed so far followed 289 logically, from verifying multicast connectivity to isolating 290 any potential faults. The next key scenario is monitoring of 291 existing, active sessions. Such groups will have a well-known 292 multicast address, and might be exchanging group membership 293 information via RTCP reports or some other out-of-band mechanism. 294 If the group is small, and feedback from each receiver is 295 important, the set of test receivers can be configured to send 296 reports to the MRM manager via unicast. If the group is large 297 and complete feedback is not necessary, the set of test receivers 298 can be frequently adjusted to represent some statistical sampling 299 of the group. The ability to send statistical reports via unicast 300 helps to improve the scalability of session monitoring by not 301 overwhelming all receivers with all reports. Finally, if the 302 group is using multicast tools that do not use RTCP and use no 303 real-time signaling, generation of a real-time list of group 304 members may be difficult to create. Other techniques will have 305 to be used. One network-layer approach might be to use SNMP 306 information to find the set of links in the multicast tree. A 307 more simple approach might depend on other available information 308 like the fact that most users start the multicast tool via a WWW 309 page. In this case, HTTP server logs can be used to estimate 310 group membership. 312 * Fault Logging: In the case when session monitoring identifies 313 the existence of a fault, a range of fault logging functions may 314 be required. At one extreme, the MRM manager may simply need to 315 be alerted when faults occur so that appropriate investigative 316 measures can be taken. At the other extreme, service contracts 317 may depend on the provision of service with certain guarantees. 318 Any outages will need to be closely tracked. These two extremes 319 again demonstrate the need for MRM to be flexible. In particular, 320 when faults need to be closely monitored and logged, a wide-scale 321 outage may itself cause a heavy load on the network. While 322 identifying the exact load capable of being supported by a 323 distressed network is beyond the scope of MRM, MRM does and will 324 support scalability and aggregation functions. 326 8. Security 328 Security issues are discussed in the MRM protocol description [MRM]. 330 9. Authors' Addresses 332 Kevin Almeroth 333 Department of Computer Science 334 University of California 335 Santa Barbara, CA 93106-5110 336 USA 337 almeroth@cs.ucsb.edu 339 Liming Wei 340 cisco Systems, Inc. 341 170 West Tasman Drive 342 San Jose, CA 95134 343 USA 344 lwei@cisco.com 346 10. References 348 [MRM] L. Wei, and D. Farinacci, "Multicast Routing Monitor (MRM)", 349 IETF Internet-Draft, draft-ietf-mboned-mrm-*.txt, 350 February 1999. 352 [RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 353 "RTP: A Transport Protocol for Real-Time Applications", 354 IETF RFC 1889, January 1996. 356 [SNMPV1] J. Case, M. Fedor, M. Schoffstall, and J. Davin, "Simple 357 Network Management Protocol", IETF RFC 1157, May 1990. 359 [SNMPV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, 360 "Protocol Operations for Version 2 of the Simple Network 361 Management Protocol (SNMPv2)", IETF RFC 1905, January 1996. 363 [MVIEW ] D. Thaler, "Mview Tool", 364 http://www.merit.edu/~mbone/mviewdoc/Welcome.html. 366 [MSTAT] B. Fenner, et al., "Mstat", Available as part of mrouted at 367 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/. 369 [MHEALTH] D. Makofske, and K. Almeroth, "Mhealth -- Real-Time Multicast 370 Tree Health Monitoring Tool", http://imj.ucsb.edu/mhealth/, 371 August 1998. 373 [RTPMON] A. Swan, and D. Bacher, "RTPmon", 374 ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/, January 1997. 376 [MULTIMON] J. Robinson, and J. Stewart, "MultiMON 2.0 -- Multicast 377 Network Monitor", http://www.merci.crc.ca/mbone/MultiMON/, 378 August 1998. 380 [MTRACE1] B. Fenner, et al., "Multicast Traceroute (mtrace) 5.2", 381 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/ 382 September 1998. 384 [MTRACE2] B. Fenner, and S. Casner, "A `traceroute' Facility for IP 385 Multicast", IETF Internet-Draft, 386 draft-ietf-idmr-traceroute-ipm-*.txt, November 1995. 388 [RTPNEW] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 389 "RTP: A Transport Protocol for Real-Time Applications", 390 IETF Internet-Draft, draft-ietf-avt-rtp-new-*.txt", 391 November 1998. 393 [MDH] D. Thaler, and B. Aboba, "Multicast Debugging Handbook", 394 IETF Internet-Draft, draft-ietf-mboned-mdh-*.txt, 395 October 1998.