INTERNET DRAFT Kamil Sarac, UTD draft-sarac-mping-00.txt Kevin Almeroth, UCSB Expires: June 2004 MPing: A Ping Utility for IP Multicast draft-sarac-mping-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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. Internet Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a mechanism for discovering multicast reachability between end systems within/between multicast enabled networks. It uses request/response messages to verify multicast reachability between the local site and a remote site. With this utility, multicast users can test if they can successfully join a multicast group of a remote source and receiver its data. Sarac,Almeroth [Page 1] draft-sarac-mping-00.txt January 2004 1. Introduction Verifying reachability between multicast enabled networks is an important management task. Multicast data propagates on forwarding paths toward the receivers. As the receivers join and leave multicast groups, these paths are dynamically created and maintained by the routers . In addition, the join mechanism does not use any feedback. As a result, problems due to lack of multicast reachability become difficult to detect. Current approaches to verify multicast reachability consist of a number of monitoring efforts that depend on voluntary participation from multicast users in collecting the reachability information among a number of multicast enabled sites. These efforts include sdr-monitor of UC Santa Barbara, Multicast Beacon of NLANR, and Multicast Tester of MulticastTech.com. The collected information in these systems give a general reachability picture for the overall multicast infrastructure. Even though these systems are useful for the multicast community in understanding the reachability status of the multicast infrastructure, they do not really help a network administrator to detect and debug a particular reachability problem between his/her network and a remote one. As a result, mechanisms are needed to help network administrators to verify the reachability status between their networks and the remote ones. In unicast, ICMP Echo Request/Reply based PING tool provides a convenient approach to discover unicast reachability between two systems in the network. For multicast, this mechanism has not been considered very useful. In multicast, PING requests are sent to multicast group address and these requests trigger group receivers to send PING responses to the PINGing host via unicast. This operation informs an end system about the fact that there are a number of receivers that received the PING request on the group address. Contrary to the utility of unicast PING, this mechanism does not help us to verify multicast reachability between two given end systems in the network. In addition, the mechanism is vulnerable to feedback implosion problem. Because of these reasons, this approach is not put into practical use by network operators. In this draft, we propose a multicast ping utility that can be used to discover multicast reachability between a local site and a remote site. We call this utility MPING. MPING can be used to verify multicast reachability between the local site (as potential receiver) and a remote site (as potential multicast source). This utility can be very helpful for network operators to debug potential multicast reachability problems between their networks and the remote ones. Sarac,Almeroth [Page 2] draft-sarac-mping-00.txt January 2004 2. MPING Protocol Operation The main idea in MPING is to use a well known multicast group address (MPING.MCAST.NET) to exchange an MPING request and response messages between the local host and a remote host. More specifically, MPING involves the below message exchanges between the local host R and a remote host S: 1) MPING request: This can be implemented as a source specific join request to (S,MPING.MCAST.NET) multicast group address. Using the source filtering support provided by IGMPv3, R sends a Membership Report that includes a join request to above group address. The Designated Router (DR) at R's site creates a PIM-Join message for (S,MPING.MCAST.NET) and forwards it toward S. When the join request reaches the DR at S's site, this router needs to inform S about the MPING request. This can be achieved by introducing a new message type to IGMP protocol. When a DR receives a join request specifically for the MPING.MCAST.NET group of a local host, it will use this new message to inform the host about the incoming MPING request. 2) MPING response: On receiving the MPING request, the host S creates and sends a MPING response back to the MPINGing host R. The MPING response is a special control message that is sent to (S,MPING.MCAST.NET) multicast group address by S. This control message propagates on the established multicast forwarding path toward R. 3) LEAVE message: On receiving the MPING response or on timeout, the MPINGing host R sends a IGMP Membership Report to leave the (S,MPING.MCAST.NET) multicast group. Consequently, the DR at R's site sends a PIM-Leave message toward the S's site to resolve the multicast forwarding path in the network. The above mechanism helps an end host R to verify multicast reachability between itself as a potential receiver and a remote host S as a potential multicast sender. The MPING response returned by S may include some useful information as follows: 1) S may include the list of multicast group addresses that it is currently sourcing data for. 2) MPING request can be answered by the DR router at S's site and the response can still contain the above information. This can remove the dependency on the host machines to implement the required MPING functionality in their operating systems. This approach assumes that the router based deployment of MPING is easier than end host based deployment. Sarac,Almeroth [Page 3] draft-sarac-mping-00.txt January 2004 3. Multiple Simultaneous MPING Requests One issue with the above mechanism is the interaction of multiple simultaneous MPING requests going toward an end host S. Due to the possibility of multiple simultaneous requests, a MPING request may not reach the source site but instead may graft on the corresponding multicast tree in the middle of the network. By the time the MPING request reaches a router on the multicast tree, the MPING response may have already been sent by the queried host and this response may have already crossed this grafting on-tree router. In this situation, the PIM-Join message corresponding the second MPING request may not return a MPING response. As a result, the second host may mistakenly conclude the lack of reachability toward the source. As an example, consider the example scenario in Figure 1. In this scenario, an end host K sends a MPING request toward a remote end host S. This request creates the multicast forwarding path between K and S in the network which includes a router A. On receiving the request, the end host S sends a MPING response back to K on the (S,MPING.MCAST.NET) multicast group. Assume that just after this MPING response passes the router A toward its destination K, the router A receives a second MPING request that has originated from end host L. Since the router A is already on the multicast tree, instead of forwarding this new MPING request (which is nothing but a PIM-Join message for the (S,MPING.MCAST.NET) multicast group) it will graft this new branch on the tree. However, since the MPING response has already passed the router A, this second MPING request will not result in a MPING response. And this situation may be mistakenly interpreted by the end host L as lack of reachability between L and S. ----- | S | ----- | | | ----- | A | ----- /\ / \ / \ / \ ----- ----- | K | | L | ----- ----- Figure 1. A sample scenario with multiple MPING requests. Sarac,Almeroth [Page 4] draft-sarac-mping-00.txt January 2004 In the above situation, before the end host L decides on the lack of reachability, it may need to run several MPING requests toward the end host S. In addition to this, we require the end host S to send multiple MPING responses with some periodicity (every 5 seconds) up to some defined time (up to 10 responses). This will increase the chances for L to receive a response to its MPING request. In the above example scenario, when the end host L sends its MPING request, it will wait for over 5 seconds to receive a response from the end host S. By the time the MPING request of L arrives the router A, if S has not sent out 10 responses yet, the end host L will receive a response for its MPING request. On the other hand, if the end host S already sent out 10 responses, we expect the end host K to receive a MPING response and then send a Leave message to resolve the previously created multicast path between its site toward the S's site. The Leave message will cause the multicast states to be removed in the routers between K and A. At this point, when the end host L waits for 5 seconds without receiving any MPING responses, it will also send a Leave message and this message will resolve the multicast forwarding path between itself and S. Then, the end host L will initiate a second MPING request which will most likely go all the way toward S's site and will result in a MPING response. Note that even if this second MPING request gets grafted on the multicast tree before it reaches S's site (due to potentially another MPING request from another MPINGing end host), because of the repeated MPING responses coming from the end host S, it will most likely receive a MPING response from S. 4. Required Modifications MPING requires a few modifications to routers and end hosts to be able to realize its function. These modifications are discussed below. 4.1 Required Modifications to End Systems End systems need to support a new IGMP message type for MPING. On receiving this IGMP message, they will create and send a number of responses to their MPING.MCAST.NET group address. Optionally these responses may include information about the multicast groups that this host is sourcing data currently. 4.2 Required Modifications to Routers Similar to end systems, edge routers need to be modified to recognize MPING requests and act on them. That is, on receiving a PIM-Join for (S,MPING.MCAST.NET) for a host S in its directly Sarac,Almeroth [Page 5] draft-sarac-mping-00.txt January 2004 attached subnet, a router will create an IGMP message and forward it to the end system to inform it about the MPING request. Optionally, routers may also participate in MPING operation by sending MPING responses on behalf of their local end hosts as discussed in Section 3. 5. Limitations The MPING mechanism presented in this draft is useful for verifying multicast reachability among remote end hosts. The maximum benefit of this mechanism can be realized with wide scale deployment in the network. In other words, the lack of MPING deployment at a multicast site may cause a MPINGing host to draw wrong conclusions about the reachability status to this site. Compared to end host deployment, we expect that MPING deployment in DR routers is relatively easier. In addition, the service provided by this utility is most useful for network administrators for debugging multicast services in their network. This fact should give strong incentives to network administrators for deploying the service in their routers. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [3]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Author's Address Kamil Sarac Department of Computer Science University of Texas at Dallas Richardson, TX 75083, USA Kevin C. Almeroth Department of Computer Science University of California Santa Barbara Santa Barbara, CA 93106, USA Sarac,Almeroth [Page 8]