BOF MultiMob D. von Hugo Internet Draft Deutsche Telekom Intended status: Informational April 25, 2008 Expires: October 25, 2008 Agent-based multicast support for moving networks (NEMO) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 October 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile Network Nodes (MNNs). The MR handles all routing related tasks to provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also subscribes to multicast groups and forwards emerging multicast von Hugo Expires October 25, 2008 [Page 1] Internet-Draft Agent-based NEMO Multicast October 2007 traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the multicast tree. In the MR a corresponding functionality is defined which decides on the location of the specific agent to be used for a distinct multicast traffic. Conventions used in this document 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 [1]. Table of Contents 1. Introduction...................................................2 2. NEMO Multicast.................................................3 2.1. Multicast Agent procedure.................................4 3. Open issues....................................................8 4. Security considerations........................................8 5. IANA considerations............................................8 6. Conclusions....................................................8 7. Acknowledgments................................................8 8. References.....................................................9 8.1. Normative References......................................9 8.2. Informative References....................................9 Author's Address..................................................9 Intellectual Property Statement..................................10 Disclaimer of Validity...........................................10 1. Introduction IP Multicast is a resource efficient measure for many promising new mobile applications which often require definite QoS degrees and low delay characteristics (e.g. for video streaming). The regular change of the Point of Attachment (PoA) to the access network infrastructure due to mobility, however, is a challenge to preservation of a continuously high quality of multicast service: either routing paths may increase unduly high or a frequent update of branches or even - in case of a moving source of multicast traffic - of the complete multicast tree will occur. A detailed comparison of several approaches towards multicast mobility has been provided in [11]. However, an efficient solution to the problem turns out to be complex and hence will require effort in processing power and energy consumption. Thus the implementation of such a solution at a Mobile Router (MR) instead of each individual Mobile Node (MN) will contribute to overall resource savings, as with a MR within a MOving NEtwork (NEMO) a single entity for mobile multicast control will serve a plurality of terminal nodes. von Hugo Expires October 25, 2008 [Page 2] Internet-Draft Agent-based NEMO Multicast October 2007 This document introduces an approach for mobile IPv6 multicast listeners and senders located within NEMOs. A NEMO is characterised by a MR and several Mobile Network Nodes (MNNs). The terminology used in this document remains conformal to the definitions in the corresponding NEMO document [5]. All mobility related functionalities are performed by the MR on behalf of the MNNs as specified by the NEMO basic support protocol [2]. Here additionally the MR also manages Multicast subscription and traffic forwarding for the nodes inside the NEMO. The approach described in the following was implemented within the framework of ongoing EU IST project Daidalos (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services [9, 13]). An entity was developped which controls multicast traffic distribution and reception within the NEMO by means of deciding and selecting the way to handle multicast, i.e. the routing path to be chosen. 2. NEMO Multicast Control of mobile multicast service related to NEMO is governed by the following general principle: All corresponding traffic emerging and terminating inside the NEMO is handled via the MR without interception from outside. The MR has to subscribe to multicast groups as well as send traffic to multicast addresses on behalf of any node inside the NEMO. In case the requested multicast traffic is not sent from another node within the NEMO the MR may join the groups via the local Access Router (AR) or via a bi-directional tunnel (BT) to the Home Agent (HA). This procedure has already been described in Mobile IPv6 [3]. Correspondingly packets to a multicast groups may be sent via the local AR or via the tunnel between HA and MR. Each of both approaches has advantages and drawbacks depending on the MR's velocity in terms of frequency of change of PoA (handover rate). In case of high handover rate the remote subscription (RS) at the local AR would result in frequent update of subscription status or even re-construction of the whole multicast tree. In case of zero velocity of the MR or slow movement compared to session duration the BT approach would result in non-optimised routing and long delay. This draft proposes the introduction of a new logical entity to support mobile multicast reception and transmission. A Multicast Anchor Agent (MAA) is a MultiCast Router enabled to receive and forward Multicast traffic by a multicast routing protocol. The dedicated MAA for a NEMO SHOULD be located in between the AR a NEMO is attached to and the HA of the NEMO's MR. All multicast data aimed at nodes outside the NEMO are tunnelled to the MAA to separate mobility issues from the multicast tree. Procedures how to identify potential MAAs and criteria for the algorithm used to select the optimised MAA are described hereafter. The basic principle is to find the trade-off between optimised routing for multicast traffic and routing path von Hugo Expires October 25, 2008 [Page 3] Internet-Draft Agent-based NEMO Multicast October 2007 re-arrangement effort due to NEMO movement characteristics. Choice for the MAA MUST be governed by the attempt to further reduce time delay and overhead effort e.g. on path re-construction after handover. The MAA approach combines the strengths of BT in terms of low multicast tree reconstruction and RS in terms of minimum routing path distance, respectively, while counteracting their disadvantages. 2.1. Multicast Agent procedure Upon subscription of an MNN within the NEMO to a multicast group, the MR forwards the multicast data via a dedicated tunnel to the MAA which to choose the MR has decided on. In case of subscription as receiver the request is forwarded utilizing the MLDv2 (Multicast Listener Discovery Version 2) [4] protocol. In case of transmission of originating traffic addressed to a multicast group the traffic data are sent to the MAA for further distribution. Corresponding multicast traffic received at the MAA is subsequently forwarded by the MAA back to the MR via the bi-directional tunnel. This MLD-proxy functionality has been introduced in RFC 4605 [8]. The applicability to mobile nodes has been described in [10] for mobile nodes with the HA as MLD-proxy similar to an MAA. Detection of a set of candidate MAAs SHOULD to be performed by the MR before applying an algorithm to decide on the best suited serving MAA for a specific multicast service. The set MAY contain the MR's HA, the current AR, an AR the MR has attached to previously, and a dedicated hierarchical router advertised as MAA. The approach to decide dynamically on an AR as optimal Multicast Agent named Dynamic Multicast Agent (DMA) has been proposed in [12]. Instead of performing selection and decision on the site of the Multicast agent should at the AR we propose to bind this mobile multicast feature to the MR functionality. Thus it is not required to update every AR in any network with the intelligent decision algorithm thus reducing the affect to the access network infrastructure. Also due to the additional feature taking into account the multicast service charcteristic the functionality is more advantageous to locate near source and receiver of the multicast traffic, i.e. within the NEMO containing those nodes. On the other hand, the mobile multicast control entity may be adapted to be implemented directly at future mobile nodes. Multicast traffic is characterised e.g. by session duration, direction to or from the NEMO, and service parameters as e.g. QoS requirements. This information MUST be transferred to the MR together with the subscription request. A potential MAA is characterised by existing subscription status and path distance to the MR. This information MAY von Hugo Expires October 25, 2008 [Page 4] Internet-Draft Agent-based NEMO Multicast October 2007 be collected by the MR via MLD messages sent, e.g. Multicast Address Specific Query. Derivation of distance may be done via already established or correspondingly adapted functionalities, as e.g. described in [7]. NEMO movement information in terms of frequency of change of PoA (handover rate) is typically available at the MR thanks to NEMO mobility management protocol [2]. By default and in case of high handover rate the MR's HA SHOULD be selected as MAA thus representing the BT approach. In case of zero velocity of the MR or slow movement compared to session duration the current AR SHOULD be chosen as MAA following RS method. Depending on the actual decision also multiple paths towards different MAAs set up via a tunnel mechanism may be used for different multicast groups (flows/sessions) and traffic directions (source/reception). To summarise the tasks of new functional entities to be established at the MR are o to forward multicast group management messages and traffic between MNN and the multicast infrastructure via a tunnel towards the selected Multicast Agent (MAA at current AR, old or new AR, MR's HA or hierarchical Multicast Agent) o to keep and update address, distance and multicast group subscription status as entries for the current and former Multicast Agents to provide information for dynamic selection of the actually used Multicast Agent (default value is MR's HA) o to retrieve current AR information and handover status o to decide on optimum Multicast Agent based on movement, distance, AR subscription status, and session/flow information An overview on the exchanged messages and initiated traffic flow between an end user at the MNN and the corresponding agent is shown in Figure 1 for a typical example. The agent is connected to a Multicast (MC) environment which is able to transport MC traffic. Here the MAA may resemble also a list of different candidate MAAs which also contains NEMO-HA and AR beside other MCRs located in the access network in between. By 'MCAS Query' a Multicast Address Specific Query as defined in [4] is denoted. To decide on a new MAA the MR must send MCAS Queries to all candidate MAAs to learn about the subscription state there. By SCR the State Change Report message definde in MLDv2 is denoted. After decision for a new MAA the old MAA MAY be informed via a SCR expressing its desire to stop listening to the specific sources to reduce overall network load. von Hugo Expires October 25, 2008 [Page 5] Internet-Draft Agent-based NEMO Multicast October 2007 MNN NEMO-MR AR MAA NEMO-HA | | | | | |--subscription->|--------------tunnelled MLD report--------->|<=MC | |<----------tunnelled MC data forwarding-----| |<---delivery----| | | | | | | | | |--sending-data->| | | | | |-----------tunnelled data forwarding------->|<=MC | | | | | | (1) HO occurrence: retrieving MAA list information | | | | | | | |---MCAS query-->| | | | |<--MLD report---| | | | |----------MCAS query---------->| | | |<---------MLD report-----------| | | |--------------------MCAS query------------->| | |<-------------------MLD report--------------| | | | | | | Decision on new MCR (AR) | | | | | | | | | |---MLD report-->| | | | |<--MC data fwd--|<=MC============================ |<---delivery----| | | | | |-----------------MLD SCR------------------->| |--sending-data->| | | | | |---data fwd---->|<=MC============================ | | | | | | (2) HO occurrence: retrieving MAA list information | | | | | | | |---MCAS query-->| | | | |<--MLD report---| | | | |----------MCAS query---------->| | | |<---------MLD report-----------| | | |--------------------MCAS query------------->| | |<-------------------MLD report--------------| | | | | | | Decision on new MCR (MAA) | | | | | | | | | | | | | | |---------MLD report----------->| | | |<-------MC data fwd------------|<=MC============= |<---delivery----| | | | |--sending-data->| | | | | |------------data fwd---------->|<=MC============= | | | | | Figure 1 Message flow chart for NEMO-MR and Multicast agent von Hugo Expires October 25, 2008 [Page 6] Internet-Draft Agent-based NEMO Multicast October 2007 At start-up of a multicast subscription at an MNN the list maintained at the NEMO-MR may only contain the NEMO-HA and the current AR. We assume that speed of the NEMO is high, i.e. the reciprocal of HO rate (inter-HO period) is small in comparison to the duration expected for the multicast session. In this case NEMO-MR MAY immediately decide for NEMO-HA as best suited MAA. NEMO-MR therefore transmits the MLD report via the tunnel to NEMO-HA and delivers Multicast data, correspondingly received at this tunnel, to the MNN. Similarily data sent by the MNN to a multicast group address MUST be forwarded by NEMO-MR to NEMO-HA via the same tunnel. Upon a HO (1) of the NEMO to a new AR the NEMO-MR includes the new AR to the MAA list and starts the optimisation routine by sending to all MAAs in the list (i.e. NEMO-HA, old AR, and new current AR) an MCAS query message. Upon receiption of corresponding MLD report messages as answers NEMO-MR is able to collect information on all potential MAAs in its list. When we assume that speed of the NEMO has been reduced considerably (e.g. when a train approaches a station) the inter-HO period will be comparable to the duration of a multicast session. On the other hand, there is no existing subscription at an MAA (e.g. old AR) but the NEMO-HA. Due to the large path distance to NEMO-HA the algorithm will decide for the current AR (located nearby at a short distance) as new MAA. Subsequently the NEMO-MR forwards multicast group subscription to the AR to deliver correspondingly received traffic data to the MNN. For reasons of network load reduction NEMO-MR MAY transmit new status to the NEMO-HA to leave the multicast group in case no other listener has subscribed there. After some time the NEMO speed will increase again (e.g. the train leaves the station). The next HO (2) starts again an optimisation routine by sending MCAS queries to all MAAs within the list which meanwhile contains two old ARs. As the recently joined AR still has subscribed to the multicast group and not yet a high enough HO rate at the MR has been achieved, the decision at the MR may be for the recently left AR as MAA. Multicast group subscription is reported (again) to the MAA, however, now from a different Care-of Address. Via a check of the MAA's IP address the identity of former and new MAA is verified. Therefore an update on multicast subscription status at the old MAA MUST NOT be sent. After establishment of the new MAA multicast data correspondingly received at the MR is delivered to MNN and multicast traffic originating within the NEMO will be forwarded to the MAA. von Hugo Expires October 25, 2008 [Page 7] Internet-Draft Agent-based NEMO Multicast October 2007 3. Open issues The approach described above up to now only considers Local Fixed Nodes (LFNs) as MNNs. Further optimisation of multicast support for the situation of Visiting Mobile Nodes (VMNs) and the attachmant of further NEMOs to an MR (nested NEMO) requires measures to transfer beside multicast group information also history on prior assigned MAAs to update the data base with. Also the investigation on how to proceed to a proactive decision for proper MMA during handover would require further investigation which is currently out of scope for the document. 4. Security Considerations This document covers an approach to support multicast service for Moving Networks. Security issues considered for NEMO [2] also apply here. Threats for multicast group control messages and issues to verify a multicast agent's identity have to be addressed by future solutions. 5. IANA Considerations No assumptions on IANA registry have been regarded in this draft. Therefore this document has no actions for IANA. 6. Conclusions Within this draft an approach for more efficient mobile multicast data communication with respect to moving networks has been presented. An improved routing solutions in the framework of IPv6 network mobility as enabled by IETF protocol NEMO (RFC 3963 [2]) has been developed and implemented within the Daidalos I demonstrator [9] operated under Linux. The approach to increase efficiency of multicast traffic in mobile networks is based on a proposed decision procedure to optimise the choice of the serving multicast agent which relies on characteristics as service parameters, traffic origination, and rate of movement of the mobile networks. 7. Acknowledgments The author would like to thank his colleagues in the EU-funded DAIDALOS project, in the framework of which this work has been partly performed. Special thanks to Holger Kahle and Jakob Belschner for their discussions and invaluable help in implementation work. Valuable comments and suggestions by Behcet Sarikaya, Matthias Waehlisch, and Gerhard Hasslinger are gratefully acknowledged. von Hugo Expires October 25, 2008 [Page 8] Internet-Draft Agent-based NEMO Multicast October 2007 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6"; RFC 3775, Internet Engineering Task Force, June 2004. [4] Vida, R. and Costa, L., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [5] Ernst, T. and Lach, H.-Y., "Network Mobility Support Terminology", RFC 4885, July 2007 [6] Conta, A. and Deering, S., "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Haberman, B. and Martin, J., "Multicast Router Discovery", RFC 4286, December 2005. [8] Fenner, B., He, H. He, Haberman, B. and Sandick, H., "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006 8.2. Informative References [9] http://www.ist-daidalos.org [10] Janneteau C., Riou, E., Petrescu, A., Olivereau, A., Lachet, H.-Y., "IPv6 Multicast for Mobile Networks with MLD-Proxy", draft-janneteau-nemo-multicast-mldproxy-00.txt, work in progess, April 2004 [11] Schmidt, Th. C. and Waehlisch, M., "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts- mmcastv6-ps-01.txt, work-in-progress, IRTF July 2007 [12] Zhang, H.-K., et al., "Mobile IPv6 Multicast with Dynamic Multicast Agent", draft-zhang-mipshop-multicast-dma-03.txt, work-in-progress, Jan. 2007. von Hugo Expires October 25, 2008 [Page 9] Internet-Draft Agent-based NEMO Multicast October 2007 [13] von Hugo, D., Kahle, H., Bernardos, C. J. and Calderon, M., "Efficient Multicast support within moving IP sub- networks", 15th IST Mobile Summit Mykonos, Greece, June 2006 Author's Address Dirk von Hugo Deutsche Telekom/T-Systems Enterprise Services Deutsche-Telekom-Allee 7 64295 Darmstadt Germany Email: dirk.hugo@t-systems.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. von Hugo Expires October 25, 2008 [Page 10] Internet-Draft Agent-based NEMO Multicast October 2007 Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. von Hugo Expires October 25, 2008 [Page 11]