BOF MultiMob D. von Hugo Internet Draft Deutsche Telekom Intended status: Informational October 9, 2007 Expires: April 11, 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 April 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). von Hugo Expires April 11, 2008 [Page 1] Internet-Draft Agent-based NEMO Multicast October 2007 Abstract This document describes an approach to support mobile IPv6 multicast listeners and senders located within a moving 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 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....................................................6 4. Security considerations........................................7 5. IANA considerations............................................7 6. Conclusions....................................................7 7. Acknowledgments................................................7 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................8 Author's Address..................................................9 Intellectual Property Statement...................................9 Disclaimer of Validity............................................9 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 von Hugo Expires April 11, 2008 [Page 2] Internet-Draft Agent-based NEMO Multicast October 2007 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 [10]. 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 MR instead of each individual MN will contribute to overall resource savings, as with a MR within a NEMO a single entity for mobile multicast control will serve a plurality of terminal nodes. This document introduces an approach for mobile IPv6 multicast listeners and senders located within moving networks (NEMO). A NEMO is characterised by a Mobile Router (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 instead of 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 [8, 12]). 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. Data aimed at nodes outside the NEMO are tunnelled to a Multicast Anchor Agent (MAA) to separate mobility issues from the multicast tree. This MAA is selected depending on multicast traffic and NEMO movement characteristics. Multicast traffic is characterised e.g. by session duration, direction to or from the NEMO, and existing subscription status. NEMO movement is typically given by frequency of change of PoA (handover rate). By default and in case of high handover rate the MR's HA is selected as MAA thus representing Mobile IPv6 [3] well-known approach of bi-directional tunnelling (BT). In case of zero velocity of the MR or slow movement compared to session duration the current Access Router (AR) is chosen as MAA i.e. the approach of remote subscription von Hugo Expires April 11, 2008 [Page 3] Internet-Draft Agent-based NEMO Multicast October 2007 (RS) also described in [3] is employed. For all other situations the dynamic allocation of the MAA will come up with either a former AR which has been previously visited or an expected future AR where the MR will likely attach to. Alternatively a dedicated static hierarchical multicast agent which is known to the MR through regular advertisements may be selected. In any case the choice for the MAA has to 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 the MR has correspondingly 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 described for the HA as MAA in [9]. To decide on an optimal MAA router the MR may operate a list of already established intermediate routers (e.g. former ARs) to subscribe to the multicast group on behalf of the MR. Such a technique of using an AR as a Dynamic Multicast Agent (DMA) has been proposed in [11]. In extension to that approach this draft introduces an entity at the MR which performs selection and decision on the site where the Multicast agent should be located. Advantage of this approach is that the access network infrastructure is less affected by required update of functionality. On the other hand the mobile multicast control entity may be adapted to usage at future mobile nodes with corresponding capability. The selection procedure at the MR entity is done via an intelligent algorithm which uses information on the current movement of the MR (handover rate) and the distance between MR and a potential MAA (amount of routing path hops). For this the MR maintains a data base of recorded NEMO attachment history and checks path increment of recently visited PoAs or ARs as well as potential new candidates. A bi-directional tunnel established between MR and old AR e.g. via Generic Packet Tunneling described in RFC 2473 [6] is used for von Hugo Expires April 11, 2008 [Page 4] Internet-Draft Agent-based NEMO Multicast October 2007 forwarding multicast group management messages and multicast traffic. Derivation of distance may be done via already established or correspondingly adapted functionalities as e.g. described in [7]. The MR may send out an MLD query to a new candidate MAA, the reply on which contains the distance in terms of number of hops. In case of an existing multicast relation the actual group management messages allow for hop count at receiver side via header hop limit decremental analysis. Actual Multicast group subscription at the different (old ones and currently serving) ARs is also taken into account to re-use existing group relations and already transmitted/received multicast traffic there in order to save amount of subscription messages and transmission resources. 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 end user at MNN and corresponding agent with connection to Multicast environment is shown in Figure 1. Here the MAA may be located at any other node in the access network in between the current AR and the MR's HA. MC denotes the ability of a node to receive and transmit MultiCast traffic and group management messages via protocols as PIM etc. within a Multicast enabled environment. von Hugo Expires April 11, 2008 [Page 5] Internet-Draft Agent-based NEMO Multicast October 2007 MNN NEMO-MR AR DMA NEMO-HA | | | | | |--subscription->|--------------tunnelled MLD report--------->|<=MC | |<----------tunnelled MCast data forwarding--| |<---delivery----| | | | | | | | | |--sending-data->| | | | | |-----------tunnelled data forwarding------->|<=MC | | | | | | Decision on new MCR (AR) | | | | | | | | | |---MLD report-->|<=MC============================ | |<-MC data fwd---| | | |<---delivery----| | | | | |---------------tunnelled MLD done---------->| |--sending-data->| | | | | |---data fwd---->|<=MC============================ | | | | | | |---MLD query------------------>| | | | | | | | |<---MLD report-----------------| | | | | | | | Decision on new MCR (DMA) | | | | | | | | | |---MLD report----------------->| | | |<-----------MC data fwd--------|<=MC============= | |---MLD done---->| | | |<---delivery----| | | | |--sending-data->| | | | | |---data fwd------------------->|<=MC============= | | | | | | | | | | | | | | | Figure 1 Message flow chart for NEMO-MR and Multicast agent 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. von Hugo Expires April 11, 2008 [Page 6] Internet-Draft Agent-based NEMO Multicast October 2007 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 [9] also apply here. Threats for Multicast group control messages and issues to verify a Multicast agents 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. 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 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. This document was prepared using 2-Word-v2.0.template.dot. von Hugo Expires April 11, 2008 [Page 7] 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.2. Informative References [8] http://www.ist-daidalos.org [9] 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 [10] 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 [11] Zhang, H.-K., et al., "Mobile IPv6 Multicast with Dynamic Multicast Agent", draft-zhang-mipshop-multicast-dma-03.txt, work-in-progress, Jan. 2007. [12] 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 von Hugo Expires April 11, 2008 [Page 8] Internet-Draft Agent-based NEMO Multicast October 2007 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 April 11, 2008 [Page 9] Internet-Draft Agent-based NEMO Multicast October 2007 Copyright Statement Copyright (C) The IETF Trust (2007). 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 April 11, 2008 [Page 10]