Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: May 9, 2008 Huawei USA November 6, 2007 Hybrid Subscription for Multicast Reciever Mobility in MIPv6 draft-xia-multimob-hybrid-00.txt 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 May 9, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xia & Sarikaya Expires May 9, 2008 [Page 1] Internet-Draft Optimization Multicast November 2007 Abstract In MIPv6 specification, there are two basic methods for mobile multicast: 1) via a bi-directional tunnel from MN to its Home Agent;2) via a local multicast router on the foreign link being visited. In this memo, a hybrid method is introduced. MN subscribes multicast service through Home agent at first. Then, MN changes its subscription router to a local multicast router which can provide the same multicast service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Detail . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Local Multicast Service Discovery . . . . . . . . . . . . 6 4.2. Multicast Group Membership Management in HA . . . . . . . 6 5. MLDv2 Extension . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Multicast Listener Hold-Release . . . . . . . . . . . . . 6 5.2. Multicast Listening State Advertisement . . . . . . . . . 7 5.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Reserved and Checksum . . . . . . . . . . . . . . . . 8 5.2.3. Nr of Mcast Address Records (M) . . . . . . . . . . . 8 5.2.4. Multicast Address Record . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative references . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Xia & Sarikaya Expires May 9, 2008 [Page 2] Internet-Draft Optimization Multicast November 2007 1. Introduction [I-D.irtf-mobopts-mmcastv6-ps] specifies the problem scope for a multicast mobility management which is further subdivided into two categories: multicast listener mobility and multicast sender mobility. In this memo, only the former is dealt with. The problem of achieving seamless multicast listener mobility is then further analyzed in three aspects: 1. Ensuring multicast reception even in visited networks without appropriate multicast support. 2. Realizing native multicast forwarding whenever applicable to preserve network resources and avoid data redundancy. 3. Expediting primary multicast forwarding at handovers. Items 1 and 2 are discussed in this document, while item 3 is handled in [I-D.xia-mipshop-fmip-multicast]. MIPv6 [RFC3775] has specified two basic methods for mobile multicast: 1)via a bi-directional tunnel from MN to its HA (Home Agent), which is called Home Subscription; 2) via a local multicast router on the foreign link being visited, which is called Remote Subscription. In Home Subscription, MN tunnels its multicast group membership control packets to its HA, and the HA forwards multicast packets down the tunnel to the MN . In Remote Subscription, the local multicast router MUST terminate MLD messages. These two basic methods can retain multicast communications when MN moves, but some issues still exist. o Home Subscription suffers from triangle route which is composed of MN- HA tunnel and HA-S (multicast source server) multicast tree path. When the MN is far from its HA, the data forwarding path of multicast becomes sub-optimal. o Although the multicast path in Remote Subscription is optimal, frequent handoffs of MN among subnets will produce much latency. Because when MN handovers, it will leave and re-join multicast groups frequently. As to unicast traffic, there are two possible modes in [RFC3775] for communication between the mobile node and a correspondent node, that is, bi-directional tunneling and route optimization. The former provides basic IP connectivity while MN is moving, while the latter provides efficient communication. In optimization mode, routing packets directly to the mobile node's care-of address allows the Xia & Sarikaya Expires May 9, 2008 [Page 3] Internet-Draft Optimization Multicast November 2007 shortest communications path to be used. It also eliminates congestion at the mobile node's home agent and home link. Borrowing some ideas from unicast traffic optimization, this document proposes an optimized solution for a multicast listener. Subscription from home network provides basic multicast service availability, while subscription from visited network provides optimal multicast traffic delivery. The combination of two methods is a comprehensive solution which is preliminarily referred to in [Progress and Challenges]. 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 [RFC2119]. The terminology in this document is based on the definitions in [RFC3775], in addition to the ones specified in this section. Multicast Services Capability: multicast traffic forwarding capability of a multicast router. Different multicast routers probably have different capability because of different local policy, router processing capability and so on. In this memo, MN can receive multicast traffic from HA or local AR. These two entities probably have different capability to provide multicast service because of different administrative domain, different processing capability and so on. 3. Solution Overview The Home Subscription or bi-directional tunneling relies on Mobile IPv6 architectural entities ( HA and MN ) and uses a multicast router (which is probably collocated with HA or not) on the home network. If the multicast router is physically separated from HA, the HA operates as a MLD proxy [RFC4605]. For simplification, this memo only considers the situation that HA acts as a multicast router. This simplification does not affect the operation defined in the document. To join a multicast group, MN establishes a bi-directional tunnel with its HA and tunnels its membership report message to the HA. This is encapsulated within the same tunnel header used for routing unicast packets between MN and HA. HA intercepts the membership message and sends a join message to an upstream router using multicast control protocols (e.g. [RFC4601]). Once the multicast Xia & Sarikaya Expires May 9, 2008 [Page 4] Internet-Draft Optimization Multicast November 2007 branch is established, the HA forwards the incoming multicast packets down the tunnel to the MN. When the mobile receiver moves to a new foreign network, it does not need to re-join the multicast group since the HA is already informed about its membership. This approach suffers from triangular routing across the home network, which may increase join latency. Moreover, tunnel via HA incurs overhead at the home network. With the Remote Subscription approach, MN joins a multicast group through a local multicast router on a foreign network. To join a multicast group, MN sends its membership report to the local multicast router (i.e. Access Router) located on the visited network. The local multicast router intercepts this membership report message and joins the requested multicast group. After handover to a new network, MN sends a new membership report message to a new Access Router acting as a multicast router. The main problem with the Remote Subscription is that the multicast services capability provided by HA is probably different from AR. That is, HA can join some multicast group while AR can not. Multicasting according to current standards (e.g. MLDv2 [RFC3810]) has drawbacks compared to unicasting when one applies it to commercial services. Accounting of each user's actions is not possible with multicasting as it is with unicasting. [I-D.ietf-mboned-maccnt-req] proposes requirements for AAA in well managed IP multicasting services. In MIPv6 scenario, HA is a default multicast service provider for MN. If MN wants to subscribe multicast service directly from AR, some AAA operation may be performed. So, when MN in a foreign link wants to subscribe to a multicast group, it sends its membership report to HA by default. While MN receives multicast traffic from HA, MN initiates a Remote Subscription by sending membership report. After successful Remote Subscription, MN notifies HA to stop delivery of corresponding multicast traffic, but hold the multicast membership in HA, as will be described further in the later. During handover, there is a multicast service negotiation between Previous Access Router(PAR) and New Access Router (NAR). That is, PAR presents MN's multicast services to NAR, and NAR replies with supported multicast services based on its local policy. If the multicast services (multicast group) are not supported by NAR, MN then reverts to Home Subscription . 4. Solution Detail Xia & Sarikaya Expires May 9, 2008 [Page 5] Internet-Draft Optimization Multicast November 2007 4.1. Local Multicast Service Discovery When MN wants to switch from Home Subscription to Remote Subscription, MN should learn the multicast service capability provided by local multicast routers. To do so, MN presents its existing multicast services to AR, and AR acknowledges the multicast services which can be provided locally. MN sends its existing multicast services to AR through State Change Report [RFC3810] once the IP connectivity with AR is established. AR sends a Multicast Listening State Advertisement which is detailed in Section 5.2. In this message, AR tells MN which multicast services can be provided locally, so MN switches corresponding Home Subscriptions to Remote Subscriptions. 4.2. Multicast Group Membership Management in HA When MN use Remote Subscription, HA MAY terminate its packet forwarding to the MN. However, to preserve its ability to restart fast packet forwarding, it may be desirable for HA to remain part of the multicast delivery tree. The Home Subscription is kept active by a new membership message called Multicast Listener Hold defined in Section 5.1 sent by MN to its HA. When MN performs Remote Subscription, it sends Multicast Listener Hold message to HA for stopping corresponding multicast traffic forwarding while keeping the multicast membership. When MN reverts from Remote Subscription to Home Subscription, it sends a message to restart the multicast traffic forwarding quickly. When MN wishes to leave a multicast group and sends Multicast Listener Report to HA, a specific query is supposed to be sent by HA to check if other listeners for the same group are present on the link. But because the tunnel is per MN, HA should not send the specific query message to relieve traffic. 5. MLDv2 Extension 5.1. Multicast Listener Hold-Release This message is to notify a multicast router (e.g. HA) to stop forwarding multicast data for the groups specified, but still maintain the multicast membership on that interface. The message has twofold functions: stopping forwarding a multicast traffic and resuming forwarding. The following figure is Multicast Listener Report format defined in [RFC3810]. Based on this, a code field is designed for Multicast Listener Hold-Release message. Xia & Sarikaya Expires May 9, 2008 [Page 6] Internet-Draft Optimization Multicast November 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address Record [1] | . . . ... . | Multicast Address Record [M] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type and other fields are defined in [RFC3810]. An 8-bit Code field is defined. Code value 1 is used to activate forwarding multicast traffic specified in the message, 2 is used to stop forwarding while hold the membership of the specified multicast address records. 5.2. Multicast Listening State Advertisement Multicast Listening State Advertisement is sent by multicast routers to advertise available multicast services for MN. The format of the message is similar to Multicast Listener Report Message in [RFC3810]. Xia & Sarikaya Expires May 9, 2008 [Page 7] Internet-Draft Optimization Multicast November 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [N] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.1. Type A new message type is defined , and the value SHOULD be allocated by IANA. 5.2.2. Reserved and Checksum These fields have the same meaning as the fields define in Multicast Listener Report Message [RFC3810]. 5.2.3. Nr of Mcast Address Records (M) The Nr of Mcast Address Records (M) field specifies how many Multicast Address Records are present in this Report. 5.2.4. Multicast Address Record Each Multicast Address Record is a block of fields that contain multicast groups information that MN can subscribe on the link from which the advertisement is sent. Xia & Sarikaya Expires May 9, 2008 [Page 8] Internet-Draft Optimization Multicast November 2007 6. Security Considerations Home Subscription shares bi-directional tunnel which is built for unicast traffic. HA and MN has a security association to protect the tunnel. As for Remote Subscription, there is no addition threats introduced comparing with MLDv2 [RFC3810]. 7. IANA consideration 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 9.2. Informative references [Progress and Challenges] Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", IEEE Wireless Comm., 2002. [I-D.irtf-mobopts-mmcastv6-ps] Schmidt, T. and M. Waehlisch, "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-mmcastv6-ps-01 (work in progress), July 2007. Xia & Sarikaya Expires May 9, 2008 [Page 9] Internet-Draft Optimization Multicast November 2007 [I-D.xia-mipshop-fmip-multicast] Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast Handover", draft-xia-mipshop-fmip-multicast-01 (work in progress), March 2007. [I-D.ietf-mboned-maccnt-req] He, H., "Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in progress), October 2007. Xia & Sarikaya Expires May 9, 2008 [Page 10] Internet-Draft Optimization Multicast November 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Xia & Sarikaya Expires May 9, 2008 [Page 11] Internet-Draft Optimization Multicast November 2007 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xia & Sarikaya Expires May 9, 2008 [Page 12]