idnits 2.17.1 draft-sarac-mping-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: ---------------------------------------------------------------------------- ** 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. ** 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 8) being 112 lines == It seems as if not all pages are separated by form feeds - found 5 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Kamil Sarac, UTD 3 draft-sarac-mping-00.txt Kevin Almeroth, UCSB 4 Expires: June 2004 6 MPing: A Ping Utility for IP Multicast 8 draft-sarac-mping-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. Internet Drafts are working documents of 14 the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working 16 documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or made obsolete 20 by other documents at any time. It is not appropriate to use 21 Internet Drafts as reference material or to cite them other than as 22 a "working draft" or "work in progress." 24 The list of current Internet Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This document describes a mechanism for discovering multicast 37 reachability between end systems within/between multicast enabled 38 networks. It uses request/response messages to verify multicast 39 reachability between the local site and a remote site. With this 40 utility, multicast users can test if they can successfully join a 41 multicast group of a remote source and receiver its data. 43 1. Introduction 45 Verifying reachability between multicast enabled networks is an 46 important management task. Multicast data propagates on forwarding 47 paths toward the receivers. As the receivers join and leave 48 multicast groups, these paths are dynamically created and maintained 49 by the routers . In addition, the join mechanism does not use any 50 feedback. As a result, problems due to lack of multicast 51 reachability become difficult to detect. 53 Current approaches to verify multicast reachability consist of a 54 number of monitoring efforts that depend on voluntary participation 55 from multicast users in collecting the reachability information 56 among a number of multicast enabled sites. These efforts include 57 sdr-monitor of UC Santa Barbara, Multicast Beacon of NLANR, and 58 Multicast Tester of MulticastTech.com. The collected information in 59 these systems give a general reachability picture for the overall 60 multicast infrastructure. Even though these systems are useful for 61 the multicast community in understanding the reachability status of 62 the multicast infrastructure, they do not really help a network 63 administrator to detect and debug a particular reachability problem 64 between his/her network and a remote one. As a result, mechanisms 65 are needed to help network administrators to verify the reachability 66 status between their networks and the remote ones. 68 In unicast, ICMP Echo Request/Reply based PING tool provides a 69 convenient approach to discover unicast reachability between two 70 systems in the network. For multicast, this mechanism has not been 71 considered very useful. In multicast, PING requests are sent to 72 multicast group address and these requests trigger group receivers 73 to send PING responses to the PINGing host via unicast. This 74 operation informs an end system about the fact that there are a 75 number of receivers that received the PING request on the group 76 address. Contrary to the utility of unicast PING, this mechanism 77 does not help us to verify multicast reachability between two given 78 end systems in the network. In addition, the mechanism is vulnerable 79 to feedback implosion problem. Because of these reasons, this 80 approach is not put into practical use by network operators. 82 In this draft, we propose a multicast ping utility that can be used 83 to discover multicast reachability between a local site and a remote 84 site. We call this utility MPING. MPING can be used to verify 85 multicast reachability between the local site (as potential 86 receiver) and a remote site (as potential multicast source). This 87 utility can be very helpful for network operators to debug 88 potential multicast reachability problems between their networks and 89 the remote ones. 91 2. MPING Protocol Operation 93 The main idea in MPING is to use a well known multicast group address 94 (MPING.MCAST.NET) to exchange an MPING request and response messages 95 between the local host and a remote host. More specifically, MPING 96 involves the below message exchanges between the local host R and a 97 remote host S: 99 1) MPING request: This can be implemented as a source specific join 100 request to (S,MPING.MCAST.NET) multicast group address. Using the 101 source filtering support provided by IGMPv3, R sends a Membership 102 Report that includes a join request to above group address. The 103 Designated Router (DR) at R's site creates a PIM-Join message for 104 (S,MPING.MCAST.NET) and forwards it toward S. 106 When the join request reaches the DR at S's site, this router 107 needs to inform S about the MPING request. This can be achieved 108 by introducing a new message type to IGMP protocol. When a DR 109 receives a join request specifically for the MPING.MCAST.NET 110 group of a local host, it will use this new message to inform the 111 host about the incoming MPING request. 113 2) MPING response: On receiving the MPING request, the host S 114 creates and sends a MPING response back to the MPINGing host R. 115 The MPING response is a special control message that is sent to 116 (S,MPING.MCAST.NET) multicast group address by S. This control 117 message propagates on the established multicast forwarding path 118 toward R. 120 3) LEAVE message: On receiving the MPING response or on timeout, the 121 MPINGing host R sends a IGMP Membership Report to leave the 122 (S,MPING.MCAST.NET) multicast group. Consequently, the DR at R's 123 site sends a PIM-Leave message toward the S's site to resolve the 124 multicast forwarding path in the network. 126 The above mechanism helps an end host R to verify multicast 127 reachability between itself as a potential receiver and a remote 128 host S as a potential multicast sender. The MPING response returned 129 by S may include some useful information as follows: 131 1) S may include the list of multicast group addresses that it is 132 currently sourcing data for. 134 2) MPING request can be answered by the DR router at S's site and 135 the response can still contain the above information. This can 136 remove the dependency on the host machines to implement the 137 required MPING functionality in their operating systems. This 138 approach assumes that the router based deployment of MPING is 139 easier than end host based deployment. 141 3. Multiple Simultaneous MPING Requests 143 One issue with the above mechanism is the interaction of multiple 144 simultaneous MPING requests going toward an end host S. Due to the 145 possibility of multiple simultaneous requests, a MPING request may 146 not reach the source site but instead may graft on the corresponding 147 multicast tree in the middle of the network. By the time the MPING 148 request reaches a router on the multicast tree, the MPING response 149 may have already been sent by the queried host and this response may 150 have already crossed this grafting on-tree router. In this 151 situation, the PIM-Join message corresponding the second MPING 152 request may not return a MPING response. As a result, the second 153 host may mistakenly conclude the lack of reachability toward the 154 source. 156 As an example, consider the example scenario in Figure 1. In this 157 scenario, an end host K sends a MPING request toward a remote end 158 host S. This request creates the multicast forwarding path between K 159 and S in the network which includes a router A. On receiving the 160 request, the end host S sends a MPING response back to K on the 161 (S,MPING.MCAST.NET) multicast group. Assume that just after this 162 MPING response passes the router A toward its destination K, the 163 router A receives a second MPING request that has originated from 164 end host L. Since the router A is already on the multicast tree, 165 instead of forwarding this new MPING request (which is nothing but a 166 PIM-Join message for the (S,MPING.MCAST.NET) multicast group) it 167 will graft this new branch on the tree. However, since the MPING 168 response has already passed the router A, this second MPING request 169 will not result in a MPING response. And this situation may be 170 mistakenly interpreted by the end host L as lack of reachability 171 between L and S. 173 ----- 174 | S | 175 ----- 176 | 177 | 178 | 179 ----- 180 | A | 181 ----- 182 /\ 183 / \ 184 / \ 185 / \ 186 ----- ----- 187 | K | | L | 188 ----- ----- 190 Figure 1. A sample scenario with multiple MPING requests. 192 In the above situation, before the end host L decides on the lack of 193 reachability, it may need to run several MPING requests toward the 194 end host S. In addition to this, we require the end host S to send 195 multiple MPING responses with some periodicity (every 5 seconds) up 196 to some defined time (up to 10 responses). This will increase the 197 chances for L to receive a response to its MPING request. In the 198 above example scenario, when the end host L sends its MPING request, 199 it will wait for over 5 seconds to receive a response from the end 200 host S. By the time the MPING request of L arrives the router A, if 201 S has not sent out 10 responses yet, the end host L will receive a 202 response for its MPING request. On the other hand, if the end host S 203 already sent out 10 responses, we expect the end host K to receive a 204 MPING response and then send a Leave message to resolve the 205 previously created multicast path between its site toward the S's 206 site. The Leave message will cause the multicast states to be removed 207 in the routers between K and A. At this point, when the end host L 208 waits for 5 seconds without receiving any MPING responses, it will 209 also send a Leave message and this message will resolve the multicast 210 forwarding path between itself and S. Then, the end host L will 211 initiate a second MPING request which will most likely go all the way 212 toward S's site and will result in a MPING response. Note that even 213 if this second MPING request gets grafted on the multicast tree 214 before it reaches S's site (due to potentially another MPING request 215 from another MPINGing end host), because of the repeated MPING 216 responses coming from the end host S, it will most likely receive a 217 MPING response from S. 219 4. Required Modifications 221 MPING requires a few modifications to routers and end hosts to be 222 able to realize its function. These modifications are discussed 223 below. 225 4.1 Required Modifications to End Systems 227 End systems need to support a new IGMP message type for MPING. On 228 receiving this IGMP message, they will create and send a number of 229 responses to their MPING.MCAST.NET group address. Optionally these 230 responses may include information about the multicast groups that 231 this host is sourcing data currently. 233 4.2 Required Modifications to Routers 235 Similar to end systems, edge routers need to be modified to recognize 236 MPING requests and act on them. That is, on receiving a PIM-Join for 237 (S,MPING.MCAST.NET) for a host S in its directly 238 attached subnet, a router will create an IGMP message and forward it 239 to the end system to inform it about the MPING request. Optionally, 240 routers may also participate in MPING operation by sending MPING 241 responses on behalf of their local end hosts as discussed in 242 Section 3. 244 5. Limitations 246 The MPING mechanism presented in this draft is useful for verifying 247 multicast reachability among remote end hosts. The maximum benefit of 248 this mechanism can be realized with wide scale deployment in the 249 network. In other words, the lack of MPING deployment at a multicast 250 site may cause a MPINGing host to draw wrong conclusions about the 251 reachability status to this site. Compared to end host deployment, we 252 expect that MPING deployment in DR routers is relatively easier. In 253 addition, the service provided by this utility is most useful for 254 network administrators for debugging multicast services in their 255 network. This fact should give strong incentives to network 256 administrators for deploying the service in their routers. 258 6. Intellectual Property 260 The IETF takes no position regarding the validity or scope of any 261 intellectual property or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; neither does it represent that it 265 has made any effort to identify any such rights. Information on the 266 IETF's procedures with respect to rights in standards-track and 267 standards-related documentation can be found in BCP 11 [3]. Copies 268 of claims of rights made available for publication and any assurances 269 of licenses to be made available, or the result of an attempt made to 270 obtain a general license or permission for the use of such 271 proprietary rights by implementors or users of this specification can 272 be obtained from the IETF Secretariat. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights which may cover technology that may be required to practice 277 this standard. Please address the information to the IETF Executive 278 Director. 280 7. Full Copyright Statement 282 Copyright (C) The Internet Society (2003). All Rights Reserved. 284 This document and translations of it may be copied and furnished to 285 others, and derivative works that comment on or otherwise explain it 286 or assist in its implementation may be prepared, copied, published 287 and distributed, in whole or in part, without restriction of any 288 kind, provided that the above copyright notice and this paragraph are 289 included on all such copies and derivative works. However, this 290 document itself may not be modified in any way, such as by removing 291 the copyright notice or references to the Internet Society or other 292 Internet organizations, except as needed for the purpose of 293 developing Internet standards in which case the procedures for 294 copyrights defined in the Internet Standards process must be 295 followed, or as required to translate it into languages other than 296 English. 298 The limited permissions granted above are perpetual and will not be 299 revoked by the Internet Society or its successors or assigns. This 300 document and the information contained herein is provided on an "AS 301 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 302 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 303 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 304 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 305 OR FITNESS FOR A PARTICULAR PURPOSE. 307 8. Author's Address 309 Kamil Sarac 310 Department of Computer Science 311 University of Texas at Dallas 312 Richardson, TX 75083, USA 314 Kevin C. Almeroth 315 Department of Computer Science 316 University of California Santa Barbara 317 Santa Barbara, CA 93106, USA