Pedro M. Ruiz Internet Draft Antonio F. Gmez-Skarmeta Expires: July 2004 University of Murcia January 2004 Requirements for MANET Interworking with Wired Multicast Networks draft-ruiz-manet-mcast-gw-reqs-00.txt 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." 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. This Internet-Draft will expire on July 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract A Mobile Ad hoc Network (MANET) is formed by the spontaneous association of wireless and mobile devices capable of communicating among them even when there is no networking infrastructure available. Several unicast Internet gateway mechanisms have been proposed within the IETEF MANET WG. However, the particular nature of the IP Multicast model poses some additional requirements which need to be satisfied by candidate solutions. This document aims at identifying the requirements that a multicast solution for MANET interworking with a fixed IP Multicast network should satisfy. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 1] Internet-Draft MANET mcast Interworking Requirements. January 2004 Table of Contents Status of this Memo................................................1 Copyright Notice...................................................1 Abstract...........................................................1 1. Introduction and Motivation.....................................3 2. Terminology.....................................................4 3. IP Multicast in fixed IP Networks...............................4 4. Requirements....................................................4 4.1 Compatibility with wired IP Multicast protocols..............5 4.2 RPF-Compatible Address Management and scooping...............5 4.3 Multiple Gateway Support.....................................5 4.4 Compatibility with inter-domain multicast routing mechanisms.5 4.5 Independence on the multicast routing used the wired-side....5 4.6 Efficient routing within the MANET and low overhead..........6 4.7 Scalability..................................................6 4.8 Resilience and robustness....................................6 5. Specific issues to be considered................................6 6. Security Considerations.........................................8 References.........................................................9 Author's Addresses.................................................9 Intellectual Property Statement...................................10 Full Copyright Statement..........................................10 Acknowledgment....................................................11 Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 2] Internet-Draft MANET mcast Interworking Requirements. January 2004 1. Introduction and Motivation IP Multicast communications are based on the idea of the source sending only one packet with a group address as a destination. The network will be in charge of replicating that packet only when necessary to make it reach all the destinations. That is, all the nodes that have joined the that specific group address. In addition, the sources do not have to perform any operation prior to become active sources for the multicast group. The IP Multicast Model[1] defines the way in which IP Multicast is supported in fixed networks. This model is based on three basic assumptions: 1. IP Multicast sources just send IP datagrams addressed to a Group IP address. 2. IP Multicast receivers use the IGMP (or MLD for IPv6) to join an IP Multicast group and inform IP Multicast routers about their interest in joining the group 3. Routers use IP Multicast routing protocols (e.g. PIM, DVMRP, CBT, etc) to make IP Multicast traffic flow from the senders to the receivers Nowadays, the most usual combination of protocols being used in fixed IP networks are IGMP and MLD for group memberships, PIM-SM for intra-domain multicast routing and MSDP/MBGP for inter-domain IP Multicast routing. One of the challenges which is being dealt with within the IETF MANET WG is the Internet connectivity for ad hoc networks. In fact, there are some alternatives which have been already proposed [2, 3, 4, 5] both for IPv4 and IPv6 unicast connectivity. However, the problem of IP Multicast connectivity for ad hoc networks deals with a different paradigm which requires an smooth interworking with existing protocols. In particular, there is a need for a clear identification of requirements to be supported by candidate solutions, given the special characteristics of the IP Multicast model (e.g. PIM access routers need to be aware of any active IP Multicast source so that receivers in other domains may join and receive multicast packets from that source). Different approaches may be followed in order to support an integrated IP multicast traffic distribution between MANETs and fixed IP networks. However, some of the alternatives may not be compatible with the standard IP multicast model, or might not be deployable in real networks. This document aims at identifying the requirements that a multicast solution for MANET interworking with a fixed IP Multicast network should satisfy, serving as a definition of the particular issues that need to be considered when designing a solution for that particular topic. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 3] Internet-Draft MANET mcast Interworking Requirements. January 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [6]. 3. IP Multicast in fixed IP Networks To explain how does IP multicast work in fixed networks, we have to comment on three different aspects: host-to-router signaling, intra- domain routing protocols and inter-domain routing protocols. Host-to-router signaling. Nowadays, the standard host-to-router protocol used for group membership is IGMPv2[7] (or MLD[8] for IPv6), which is implemented in most of the common operating systems. Some IGMPv3 (and MLDv2) implementations exist and are starting to be delivered with standard operating system distributions. Intra-domain multicast routing protocol. There are several multicast routing protocols which have been proposed for fixed networks. DVMRP has been the most widely used since the deployment of the first multicast networks because of its facilities to establish virtual multicast links, which formed the so called MBone. However with the advent of native IP Multicast the most widely supported and recommended IP multicast routing protocol in the Internet is PIM-SM (or its IPv6-enabled variant). Inter-domain multicast routing protocol. For the inter-domain operation several protocols are used nowadays in the Internet. On the one hand, MSDP is used for informing neighbor domains about new active sources in our domain. On the other hand, MBGP has been extended to carry not only unicast routing information but also multicast, IPv6 and many other protocols information among routing domains. Thus, the currently used multicast approach is also known as: PIM- SM/MSDP/MBGP. All these protocols operate in a very specific way that imposes several requirements for being interoperable to the multicast routing protocols used in MANETs. For example, PIM-SM requires the first hop multicast router (FHMR) to encapsulate the first packets sent by a source into PIM-Register messages, the router running the MSDP process needs to be able to know when new sources have come up in order to inform neighbor domains, etc. So, we should carefully take into account the multicast model used in fixed networks when designing and studying new approaches for multicast MANET interworking with fixed IP networks. 4. Requirements This section describes a list of requirement that should be desirable to have in any candidate mechanism providing IP Multicast Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 4] Internet-Draft MANET mcast Interworking Requirements. January 2004 interworking between MANETs and fixed IP networks (a.k.a. wired- side). 4.1 Compatibility with wired IP Multicast protocols The protocols used both within the MANET and in the wired-side MUST be interoperable. For example, the multicast routing protocols used in the Ad hoc network should be able to collaborate with those used in the access network and in the core network to effectively build multicast distribution topologies connecting every source transmitting to a group G, with all the terminals joined to that group regardless of their (ad hoc or Internet) point of attachment. 4.2 RPF-Compatible Address Management and scooping The proper address management procedures MUST be provided so that the addresses used by Ad hoc nodes attached to the Ad hoc extension, could be also used by the fixed network routers to perform Reverse Path Forwarding (RPF) checks or whatever multicast-related procedures. Efforts within the IETF towards automatic IP Multicast address management, allocation and assignment such us MADCAP[9] should also be considered when designing the proper multicast MANET address management schemes. In addition, routing approaches should be congruent with the multicast mechanisms for creating scopes. That is, candidate solutions should be able to support the network administrators in confining the multicast traffic in specific regions. Nowadays two scooping mechanisms have been defined: TTL scooping and administratively scooping. The first limits the packets according to the TTL value in the IP header while the latter uses different address ranges and boundaries to confine the traffic addressed to specific groups. 4.3 Multiple Gateway Support Candidate solutions MUST offer mechanisms to deal with multiple points of attachment to the wired-part. This functionality will serve to improve the overall performance, load balancing, higher reliability, etc. 4.4 Compatibility with inter-domain multicast routing mechanisms Our solutions should not affect the inter-domain multicast routing protocols being used in the administrative domain. In fact, the ad hoc routing extensions should be implemented in such a way that ensures that the information needed by these protocols could also be extracted from the Ad hoc extension. 4.5 Independence on the multicast routing used the wired-side The definition of the interoperation between fixed and ad hoc extensions should be done in terms of functionality and information that each part needs from the other. These rules SHOULD be generic enough to guarantee that several routing approaches could be applied in the wired-part. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 5] Internet-Draft MANET mcast Interworking Requirements. January 2004 4.6 Efficient routing within the MANET and low overhead. In addition to offer a good interoperation with the fixed infrastructure, the ad hoc routing mechanisms should be efficient and effective in providing good routes between ad hoc nodes as well. In fact, the routing protocols SHOULD still offer good routes even when no nodes in the fixed network are taking part in the communication and vice versa. In addition, candidate solutions SHOULD not impose a high overhead within the ad hoc network to prevent low-performance approaches. The performance of the multicast ad hoc routing protocols should not be significantly jeopardized. In fact, solutions demanding a high signaling overhead are well-knonwn to produce a poor performance in ad hoc network environments. 4.7 Scalability The solution for making the ad hoc extension and the fixed infrastructure protocols interoperable should preserve the basic multicast principle of scalability to support a great amount of users simultaneously. In particular, it SHOULD be interesting to preserve the anonymous nature of IP multicast in which FHMRs do not need to keep track on which are the members of any IP Multicast group. Instead of that, they only need to know whether there is some member for a particular group or not. 4.8 Resilience and robustness These approaches should be robust enough to guarantee an effective routing even when some control packets are lost, mobility creates network loops and the points of attachment to the fixed network dynamically change. 5. Specific issues to be considered For multicast hosts the process of taking part in multicast communications is quite straightforward. When they wish to send multicast traffic they simply use a class-D address as a destination and send the datagrams. When they are interested in receiving multicast traffic, they use the Internet Group Management Protocol (IGMP) as a request to their First Hop Multicast Router (FHMR). This simple operation is not automatically supported in multicast ad hoc routing protocols. So, in order to support the aforementioned requirements, multicast ad hoc routing protocols are required to deal with the following issues: 1) TTL related IGMP issues. IGMP assumes that multicast-enabled routers and its end-nodes are all directly connected through the link layer without any intermediate router. Thus, the communication between the First Hop Multicast router (FHMR) and the end nodes is performed by means of packets having a TTL of one. That is, IGMP messages cannot traverse routers unless some tunneling mechanism or IGMP-proxy is implemented. This limitation applies both for IGMP reports coming from the end-nodes towards the FHMR and for IGMP Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 6] Internet-Draft MANET mcast Interworking Requirements. January 2004 Queries coming from the FHMR towards the end-nodes. So, the correct placing of FHMRs in our architecture may very much influence both the mechanisms to deploy and the efficiency that we can achieve with our approach. 2) Shared medium related IGMP issues. The Internet Group Management Protocol (IGMP) was specially designed for shared medium networks in which one frame sent by a node can be received by all other nodes connected to the same link layer. In fact, this assumption is used by IGMP to optimize its behavior. So, as long as the router is only interested in knowing if there is any node interested in receiving a multicast group, when one of the interested nodes replies to the router with an IGMP report message, the other interested nodes do not need to reply again. The shared medium is what ensures that other nodes are going to be able to know that there have been other answers. This is used both in IGMPv1 and IGMPv2. The good point is that IGMPv3 do not need this approach to be followed. In addition, not following this approach does not break IGMP but only makes it less optimal in bandwidth usage. However this is not an issue in the currently deployed switched networks. 3) Tunneling of IGMP messages. The tunneling of IGMP messages to overcome its TTL limitation does not tend to be the better approach for scarce resources networks like Ad hoc extensions to a fixed IP Network. This kind of solutions usually led to inefficient data distribution as well as scalability problems. The protocol efficiency is damaged by means of using extra headers due to the tunneling process. The protocol scalability is also damaged by means of making the FHMR to become a single point of failure. However, the worse problem is that the FHMR has to store individual membership for every end-node instead of forwarding state of the interface. In addition the FHMR has to send a copy of each datagram to each end- node instead of sending just one datagram to the shared medium. The same limitation applies for datagrams from one of those end-nodes to the rest of end-nodes in the same network. In this case the FHMR has to redistribute these datagrams between all these nodes, which is not the proper multicast behavior. 4) Uplink and downlink support. The requirements and mechanisms needed to support multicast communications both from end terminals to fixed nodes in the core network and vice versa are different. So, in the following subsections we will need to study both approaches for every option. In general, sending multicast datagrams do not impose any requirement to the end-node but the ad hoc routing protocol should behave so that one router in the fixed IP network running PIM-SM should be able to detect such traffic and send it to the RP encapsulated in a PIM-Register message. For receiving, the end-node needs to inform the routers about the groups it wants to join and the ad hoc routing protocol should ensure that some PIM-SM router in the BAN will detect that need and join the proper multicast tree towards the RP. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 7] Internet-Draft MANET mcast Interworking Requirements. January 2004 5) Supporting roaming of terminals from and to the ad hoc network. Using IGMP for group management in the wired network is the standard way to work. However, we should also ensure that Standard-IP nodes use the same group management protocol so that they could operate in the same way when they are attached to the wired network as well as when they are in the Ad hoc extension. Otherwise, Standard-IP nodes would have to implement several group management protocol stacks. 6. Security Considerations Security requirements are not included in this version of the Internet-Draft. They will be added in future revisions. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 8] Internet-Draft MANET mcast Interworking Requirements. January 2004 References [1] Steve Deering. Host extensions for IP multicasting. RFC 1112, August 1989. [2] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A. Tuominen, "Internet Connectivity for Mobile Ad hoc networks", I-D draft-wakikawa-manet-globalv6-02.txt, November 2002. [3] Perkins, C., Belding-Royer, E. and I. Chakeres, "Internet Connectivity for Mobile Ad hoc networks", I-D draft-perkins- manet-aodvbis-00.txt, October 2003 [4] C. Jelger, T. Noel, Gateway and address autoconfiguration for IPv6 ad-hoc networks, I-D draft-jelger-manet-gateway- autoconf-v6-01.txt. Work in progress. October, 2003. [5] H. Cha, J. Park, H. Kim, Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc Networks, I-D draft-cha- manet-extended-support-globalv6-00.txt. Work in progress. October, 2003. [6] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March, 1997. [7] W. Fenner, Internet Group Management Protocol, Version 2. RFC 2236, November 1997. [8] S. Deering, W. Fenner, B. Haberman, Multicast Listener Discovery (MLD) for IPv6. RFC 2710, October, 1999. [9] Hanna, S., Patel, B. and Shah, M.: Multicast Address Dynamic Client Allocation Protocol (MADCAP), RFC 2730, December 1999 Author's Addresses Pedro M. Ruiz Dpto. Ingeniera de la Informacion y las Comunicaciones University of Murcia Facultad de Informatica Campus de Espinardo s/n E-30100 Murcia (Spain)) Phone: +34 968367646 Email: pedrom@dif.um.es Antonio F. Gomez-Skarmeta Dpto. Ingeniera de la Informacion y las Comunicaciones University of Murcia Facultad de Informatica Campus de Espinardo s/n E-30100 Murcia (Spain) Phone: +34 968364607 Email: skarmeta@dif.um.es Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 9] Internet-Draft MANET mcast Interworking Requirements. January 2004 Intellectual Property Statement 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. 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. 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 assignees. 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. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 10] Internet-Draft MANET mcast Interworking Requirements. January 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. In addition, part of this work is funded by the Spanish MCYT. Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 11]