MAGMA Working Group Greg Daley INTERNET-DRAFT Gopi Kurup Expires: December 2003 Monash University CTIE June 2003 Requirements for Mobile Multicast Clients draft-daley-magma-mobile-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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - RFC2119 [KEYW-RFC] Abstract This document describes the existing systems available for mobile devices to receive multicast data streams. It provides a case for common handling of Network Attachment Detection for moving multicast clients independent of global mobility signalling. Table of Contents Status of this Memo.......................................... 1 Abstract..................................................... 1 Daley, Kurup draft-daley-magma-mobile-00.txt [Page 1] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 Table of Contents............................................ 1 1.0 Introduction............................................. 2 1.1 Terminology............................................. 2 2.0 Multicast Client Mobility................................ 3 2.1 Using Global Mobility Signalling for Multicast.......... 4 2.2 Joining a Group on a Visited Link...................... 5 2.3 Leaving a Visited Link.................................. 5 3.0 Proposal for Handling Multicast Client Movement.......... 6 3.1 Detecting Network Attachment............................ 6 3.2 Detecting Client Detachment............................. 6 3.3 Minimizing Multicast Routing Changes.................... 7 4.0 IANA Considerations...................................... 7 5.0 Security Considerations.................................. 7 Normative References......................................... 8 Non-Normative References..................................... 8 Acknowledgements............................................. 9 Authors' Address............................................. 9 1.0 Introduction Multicast routing enables a set of applications which have scalability benefits when many nodes on a subnet (or set of links) wish to receive a common stream of data. This document describes the existing systems available for mobile devices to receive multicast data streams. Most of the work which has been previously undertaken to provide mobility support for hosts has relied upon unicast routing [MIPv6-22,3GPP-MULT]. Work on these systems aims at principally at isolating unicast address change from peer packet sources, or providing direct path unicast routing through the use of unicast care-of-addresses. In the case where a mobile device does not require reception of unicast packets, it may still have a requirement to receive multicast streams as a client. One example environment is where commuters on may be interested in updated weather or financial data, or local news services. In a dense user environment such as this, unicasting of these data streams using mobility protocols will be inefficient and may lead to excess bandwidth consumption[MULT-UMTS]. If multicast is employed as an alternative delivery mechanism to mobile hosts, there are tasks which must be performed in order to start receiving multicast data streams on a new link. Additionally, issues arise from the mobility of multicast clients which mean that Daley, Kurup draft-daley-magma-mobile-00.txt [Page 2] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 group membership information held by routers is not up-to-date. As will be described in this document, some of these issues are common to other application domains and may be handled using mechanisms in common with those systems. 1.1 Terminology IP - Internet Protocol Version 6 (IPv6)[IP6-RFC]. DAD - Duplicate Address Detection [SAA-RFC] MLD - Multicast Listener Discovery [MLD-RFC] node - a device that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. address - an IPv6-layer identifier for an interface or a set of interfaces. querier - router on the subnet which actively queries MLD state. snooping - A mechanism whereby Link-Layer devices attempt to infer multicast group membership by monitoring MLD messages. 2.0 Multicast Client Mobility MLD [MLD-RFC] defines mechanisms for joining Multicast groups on a link. This protocol's goal is to provide a mechanism for determining the presence or absence of hosts, in order that multicast routing trees may be built to deliver streams of data to these clients. Upon attaching to a link, a multicast client is instructed to send MLD Reports for each of the multicast groups which it wishes to join. When it receives a report, the Multicast Router requests a stream to Daley, Kurup draft-daley-magma-mobile-00.txt [Page 3] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 be sent to its own subnet if it is not already receiving that data. Data will then arrive if multicast senders are transmitting for the requested (S,G) pair[MLDv2-ID]. When the client is moving, there is no existing provision which allows the host to detect if it has arrived on a network where these streams already exist. Additionally, until it receives router advertisement information[ND-RFC], it may not be aware even if it is attaching to a link where it has already joined the multicast groups (for example if the Link-Layer Access Point changed, but not the IP subnet). Movement of a mobile device away from a node is problematic in that existing multicast systems propagate data on the link for a fixed interval unless the host explicitly leaves all of its multicast groups before moving to another link. While this may be possible in some link technologies where planned handovers are common [MULT- UMTS], in circumstances where this signalling is not possible, trailing multicast group memberships are left by moving nodes. 2.1 Using Global Mobility Signalling for Multicast Existing work on Mobile IPv6 attempts to avoid reliance on Multicast routing in the access networks by providing MLD support over a tunnel between a mobile multicast client and its Home Agent Router. The Home Agent is principally a device which redirects unicast packets to a host when it has moved away from its unicast Home Address' subnet. Under this scheme, multicast packets are treated in the same fashion as unicast packets and are encapsulated in IPv6 and IPSec headers before delivery to the mobile multicast client. The addition of such headers to multicast packets is problematic in that their final size may exceed link MTUs. This may lead to loss of the complete data stream since Multicast systems provide no mechanisms for resizing packets for clients on links with small MTUs. Additionally, if the multicast client happens to be on the same subnet as another device receiving this multicast data stream, it loses the scalability benefits of group membership, and each packet will be transferred across the link many times[MULT-UMTS]. Conversely, if the mobile client population for this data stream is sufficiently sparse, this may provide a reliable access to multicast traffic, without undue burden to the visited access network[MIPv6-22]. Daley, Kurup draft-daley-magma-mobile-00.txt [Page 4] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 2.2 Joining a Group on a Visited Link Tunneled Multicasting may be valid in situations where multicast data is associated with the mobile client's home network, but is not valid if information received is specific to the visited domain. For these services, at least, it is important to join multicast groups on the visited access network. This means that MNs arriving on-link will be bound to send MLD group join messages as soon as they are aware that they are on a new link. If the mobile client discovers that it is receiving a multicast data stream, but has not sent reports to join the group on this link, it is still required to join the group since the device which reported may itself be mobile and cause the group to be removed by moving to another link. In each case, the mobile client should either determine that the link is a new one, or transmit MLD group join (report) messages even if the link is the same. This second method may cause excessive multicast traffic on the link if there may be many Link-Layer handovers without changing subnet. A notable exception to this is when it is possible that MLD snooping may be in use within the access network [SNOOP-07]. In this case snooping networks will require MLD group join messages whenever the multicast client changes its Link-Layer attachment. Further investigation of the effects of MLD snooping on host mobility is required before recommendations may be made in this regard. 2.3 Leaving a Visited Link. It is worth noting that a mobile client will (by default) maintain group membership until the MLD Multicast Listener Interval expires. This entails failing to send in an MLD report after a periodic Group Query from the MLD Querier Router [MLD-RFC,MLDv2-ID]. This may lead to the multicast router continuing to send packets associated with a group to the mobile client, even if the this client has moved, and it was the only member of the group. If the mobile client is able to send an Multicast Listener Done message, this issue does not occur, although this requires the client to predict when it is about to move [FMIPv6-06,L2MANY-02]. Given that this is not the case with most mobile devices today, it is reasonable to expect that in some environments Multicast Routers may have multiple groups for which data are transmitted onto a link for absent clients. This would be a significant drain on wireless link bandwidth resources, and could even be used to deny service. Daley, Kurup draft-daley-magma-mobile-00.txt [Page 5] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 3.0 Proposal for Handling Multicast Client Movement Movement of multicast clients from subnet to subnet is likely to cause significant routing disruption to multicast routing tables, or additional bandwidth consumption. Here we outline three proposals which may be of use in reducing link utilization and multicast signalling. 3.1 Detecting Network Attachment The role of joining a group is simply that of sending an MLD Report and initiating timers. Even though this task is very simple to perform, it is required for every group the multicast client is interested in. Therefore it is valuable to avoid sending MLD reports unless it has arrived at a link where its MLD group membership has not been registered. This is particularly important if clients may attach to a the same subnet many times as part of Link-layer handover procedures. There are existing reasons for detecting whether a host is attached to a new link. For example in [MIPv6-22], mechanisms for detecting movement have been defined which may be able to provide knowledge of link identity using IPv6 Router Discovery[ND-RFC][MDO-01]. Similar requirements exist for hosts without mobility signalling, in order to determine if a session is able to maintain connectivity with currently selected addresses. It may make sense to use Router Discovery to determine the current configuration status of a link using a common method. This method could then be used for all affected sessions on the host, whether unicast or multicast. Currently enough interest exists in this field to propose a BoF Session for IETF57 on Detecting Network Attachment. 3.2 Detecting Client Detachment Access Routers on a link may have access to additional information about the presence of hosts attached to a link. This may take the form of communication with Link-Layer devices (such as wireless access points) on a link, or through communication to peer ARs within a routing domain. It may be possible for access routers to remove old multicast state when the router is certain that the mobile client has departed. For Link-Layer devices, it may be possible to associate an Link-layer identifier with the identity of a multicast client. When a wireless Daley, Kurup draft-daley-magma-mobile-00.txt [Page 6] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 Access Point indicates the removal of this Simple hysteresis mechanisms could ensure that routing state is not changed in the case where a client momentarily disconnects due to Link-Layer handover[L2TRIG-01]. Upon the multicast client's arrival at a new network, it may be possible for the new access router to initiate a context transfer with the old AR, which would remove the client's old multicast state. While it is not seen as useful to initiate multicast services on a new network using context transfer, it may be valid to remove existing state on a previous network using such protocolsp[CTPPROB]. At this stage, the use of the Context Transfer Protocol between ARs in a domain is ongoing within the SEAMOBY-WG of the IETF[CTP-02]. Additional protocols or mechanisms which define methods to communicate Link-Layer connectivity within the local subnet are underway, although no particular working group has ownership of this. 3.3 Minimizing Multicast Routing Changes If mobile devices engender sparse Multicast Routing behaviour, there may be significant cost in re-calculating and re-propagating multicast trees, to support mobile client movements. It may be necessary in some cases to defer multicast routing updates, by adopting a local tunneling solution between pairs of Access Routers[BETH,FMIPv6-06]. This would allow ARs to request data streams from a router which is known to have access to a group, without explicitly modifying global multicast routing. When routing updates are completed, the new AR sends a Multicast Listener Done message for the stream, across the tunnel. This system would have similar MTU issues to the Unicast Mobility systems described previously, except that the AR decapsulates packets once they leave the tunnel before delivery on the access network. Additionally, the role of the AR as arbiter of which groups arrive on link is maintained. At this stage, further analysis is required to determine if this mechanism is actually useful in real networks. 4.0 IANA Considerations N/A. 5.0 Security Considerations This document describes a set of existing approaches which each have their own security considerations. Daley, Kurup draft-daley-magma-mobile-00.txt [Page 7] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 Current work on Securing Neighbor Discovery [SENDIPSEC-01] may be applicable to determine trust when undertaking router discovery operations. The proposal for edge multicast tunnel establishment handovers Normative References [KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119 (BCP 14), Internet Engineering Task Force, March 1997 [ND-RFC] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [MLD-RFC] S. Deering, W. Fenner, B. Haberman. Multicast Listener Discovery (MLD) for IPv6. Request for Comments (Proposed Standard) 2710, Internet Engineering Task Force, October 1999. [MLD-SRC] B. Haberman. "Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)", Internet Draft (work in progress), September 2002. [SENDIPSEC-01] J. Arkko et al, "Secure Neighbor Discovery (SEND)", Internet Draft (work in progress), June 2003. [SNOOP-07] M. Christensen, K. Kimball, F. Solensky, "Considerations for IGMP and MLD snooping switches", Internet Draft (work in progress), April 2003. Non-Normative References [MIPv6-22] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6. Internet Draft (work in progress), May 2003. [MULT-UMTS] Mariann Hauge, Øyvind Kure,"Multicast in 3G Networks: Employment of Existing IP Multicast Protocols in UMTS", Proceedings of the 5th ACM international workshop on Wireless mobile multimedia, 2002 , Atlanta, Georgia, USA [3GPP-MULT] "Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Stage 1", 3GPP TS 22.146 version 6.2.0 Release 6, 2002. [MLDv2-ID] R. Vida et al. Multicast Listener Discovery Version 2 (MLDv2) for IPv6. Internet Draft (work in progress), June 2002. Daley, Kurup draft-daley-magma-mobile-00.txt [Page 8] INTERNET-DRAFT Mobile Multicast Client Requirements February 2003 [CTPPROB] J. Kempf (Ed.). "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374 (Informational), September 2002. [CTP-02] J. Loughney (Ed.). "Context Transfer Protocol", Internet Draft (work in progress), June 2003. [MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization in Mobile IPv6", Internet Draft (work in progress), May 2003. [FMIPv6-06] R. Koodli (Ed.). "Fast Handovers for Mobile IPv6", Internet Draft (work in progress), Mar 2003. [L2MANY-02] A. Yegin (Ed.). "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", Expired Internet Draft, June 2002, http://www.yegin.org/alper/draft- manyfolks-l2-mobilereq-02.txt [L2TRIG-01] A. Yegin "Link-layer Triggers Protocol", Internet Draft (work in progress), June 2003. Acknowledgements Alper Yegin's Contributions to the DNA-BoF mailing list have helped in describing MLD state removal mechanisms. Authors' Address: greg.daley@eng.monash.edu.au Greg Daley g.kurup@eng.monash.edu.au Gopi Kurup Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia This document expires in December 2003. Daley, Kurup draft-daley-magma-mobile-00.txt [Page 9]