Multimob working group Hui Liu Internet Draft Huawei Technologies Co.,Ltd. Category: Informational Created: June 14, 2009 Expires: December 2009 Multicast Receiver Mobility (MultiReM) Architecture draft-liu-multimob-multicast-receiver-mobility-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Liu. Expires December 14, 2009 [Page 1] Internet-Draft Multicast Receiver Mobility June 2009 Abstract This document proposes the architecture and solution options for multicast receiver mobility. The discussions are restricted only to the receiver mobility with the assumption that the multicast source and network are stationary while the receiver is in the moving state. The suggestions are given on how to integrate mobile IP and fixed multicast protocols to provide the feasible solutions, which involves the aspects of mobile receiver registration, group membership management, tunnel or optimal multicast routing, and handover optimization. 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 [RFC2119]. Table of Contents 1. Introduction.................................................2 2. Overview of Mobile Receiver Multicast........................3 3. Architecture Aspects of Mobile Receiver Multicast............5 3.1. Network Entities........................................5 3.2. Address Configuration and Registration Process..........6 3.3. Tunnel Mechanism Considerations.........................7 3.4. Group Membership Management.............................7 3.5. Multicast Tree Construction and Data Forwarding.........8 3.6. Handover Considerations................................10 3.7. Authentication and Accounting..........................15 4. Considerations for Different MIP Protocols..................15 4.1. MIPv4..................................................15 4.2. MIPv6 and DSMIPv6......................................17 4.3. PMIPv6.................................................18 5. Security Considerations.....................................19 6. Acknowledgments.............................................19 7. References..................................................19 7.1. Normative References...................................19 7.2. Informative References.................................20 Authors' Addresses.............................................21 1. Introduction This document intends to provide the architecture which allows a node to receive multicast service via multicast when it is in the Liu. Expires December 14, 2009 [Page 2] Internet-Draft Multicast Receiver Mobility June 2009 moving state. Only receiver mobility scenario is considered, with the intended service model of mobile IPTV applications. The multicast source mobility and network mobility are not within the scope of this document. The proposed scheme aims to be compatible with existing Mobile IP and fixed network IP multicast protocols and tries to integrate them efficiently to get a feasible solution. Least restrictions should be put on the underlying network, whose address family could be IPv4 or IPv6 and whose access network could be of any link types (3GPP, WLAN or WIMAX). The document is organized as: Section 2 gives the overview of mobile receiver multicast. Section 3 discusses various aspects of its architecture and solution options. Section 4 illustrates the special considerations for different MIP protocols. 2. Overview of Mobile Receiver Multicast IP Multicast mobility provides multicast service delivery when the network and/or terminals are in the moving state. It enhances the unicast mobile IP with multicast capability. If multicast service is not subscribed, the unicast mobile IP protocols should be used for tracking and managing of the mobile host, thus MIP protocols (MIPv4 [1], MIPv6 [2](or DSMIP [16]) and PMIPv6 [3],and etc.) should be used in multicast mobility architecture to establish communication relationships among the mobile node (MN), the correspondent node (CN), and the access nodes on the home and foreign network. Receiver multicast mobility has the particularities that the receiver doesn't send packets towards its CN counterpart - the multicast source, and the multicast source does not send packets directly to the receiver's address but to the multicast group address instead, thus there isn't direct communication relationship between the receiver and the multicast source and the binding processing between them is not required. Multicast receiver mobility shares with the unicast application the common process for MN and network discovery, address configuration, registration and binding between the MN and the home network. MIP makes use of tunnel for MN and CN to communicate through Home Agent and of route optimization for them to communicate directly. The tunnel mechanism has the efficiency and reliability problems and the route optimization eliminates the drawback by introducing additional signaling support between the CN and the MN. For mobile Liu. Expires December 14, 2009 [Page 3] Internet-Draft Multicast Receiver Mobility June 2009 multicast tunnel method [1][2], the home agent is responsible for joining the multicast tree on behalf of the receiver. The receiver sends the group membership report through the tunnel to the home agent and the home agent tunnels the group query and the multicast data to the receiver. It is obvious that the efficiency issue for tunnel is even worse in multicast than in the unicast case because multicast data is usually of high volume (such as video provision in IPTV), which requires the optimal multicast route method (belonging to ''remote subscription'' [17] categories) to be pursued. The multicast route optimization should be based on the multicast routing architecture. The route optimization of receiver mobile multicast is described as: the receiver sends group join to the access node on the foreign network, and the access node directly constructs the multicast tree on the foreign network, as mentioned in [18][19][20][21][22]. The adoption of multicast route optimization or the multicast tunnel mechanism should be independent of the unicast communication mechanism on the receiver, while it should depend on the capability of and the policy configured on the receiver and the foreign access network. If the receiver node itself doesn't want to rely on the foreign access node for multicast traffic forwarding, or current foreign network does not support or configured not to use optimal multicast routing, then tunnel mechanism could be adopted. Otherwise if the access network is configured to use multicast route optimization, then more efficient data delivery could be implemented. Whether the multicast tree is constructed on the foreign network or on the home network, the multicast routing mechanism should be the same as that of fixed network multicast. This is because they share the common features that only the source sends data towards the receiver and there isn't any multicast control packets exchanged directly between the source and the receiver. Thus it is feasible to reuse currently deployed fixed network multicast routing protocols. The protocols could be PIM-SM [4], PIM-SSM [5], MPLS p2mp RSVP-TE [6], MPLS p2mp LDP [23], and etc., depending upon the provider's choices. Handover issues must be considered carefully in mobile receiver multicast solution, because as the receiver connects to the new access network, the completion of configuration and establishment of new multicast forwarding states may require long process time and possibly interrupt the multicast data transmission. Thus the handover procedures should be optimized or accelerated to reduce or avoid multicast packet loss. Liu. Expires December 14, 2009 [Page 4] Internet-Draft Multicast Receiver Mobility June 2009 As a summary, the general architecture of multicast receiver mobility can be described as follows: it makes use of MIP protocols to make registration and binding of the receiver on the home network, of IGMP/MLD protocols to join and leave a group, of multicast routing protocols to construct multicast trees between the source and the receiver on home or foreign network. The tunnel and routing optimization mechanism should both be provided. Besides, special consideration should be put on how to realize seamless multicast reception during handover. The extensions of the above protocols and definition of a new protocol may be made if they are necessary to improve the performance, and attention should be taken in order not to introduce interoperability problems. 3. Architecture Aspects of Mobile Receiver Multicast 3.1. Network Entities Regardless of the type of multicast routing protocols adopted, the mobile multicast network includes the following entities: - Multicast source. It sends data to a multicast group with the destination address of the packet set to multicast group address. - First-hop router. It connects directly with the multicast source network. - Last-hop router. It connects directly with the multicast receiver network and functions as the leaf node of the multicast tree. It receives and processes the group membership reports from the receiver and initiates multicast routing protocol procedures towards the upstream router to construct the multicast tree. Sometimes the switches and routers supporting IGMP/MLD-Proxy [7] also act as the last hop, when the tree is set up simply by IGMP/MLD proxy messages. - Intermediate router. It constructs the multicast tree between the first-hop and the last-hop by multicast routing protocol (or IGMP proxy protocol). - Root node. It is a Rendezvous Point (RP) node in some cases [4] and is the first-hop router in other cases [5][6][23]. For multicast receiver mobility, all the above entities are stationary. The last hop router is the leaf-node of the multicast tree and may or may not coexist with network-side MIP access node (defined in different MIP protocols as different entities as shown below) which takes the duty of mobile management such as detection Liu. Expires December 14, 2009 [Page 5] Internet-Draft Multicast Receiver Mobility June 2009 and configuration of the mobile receiver. For convenience of illustration, it is assumed in the following parts that the multicast tree last-hop and the mobile IP access node are located on the same node. IPTV networks usually deploy video server on the edge of the network. The multicast tree is constructed (sometimes statically) between the server and the program source and the program content may be pre- pushed to the server. The receiver connects to the server and after the subscription downloads the content from the server. In this case the server is the last hop of the receiver. The access node of the receiver on the home network is the home agent in MIPv4 and (DS)MIPv6, or Local Mobility Anchor (LMA) in PMIPv6. For (DS)MIPv6 and MIPv4 of co-located mode, there is no definite entity defined on the foreign network engaged in the MIP signaling processing, then the access router on the foreign network functions as the mobile multicast access node. In other cases, the foreign agent of MIPv4 (of foreign-agent mode) and Mobile Access Gateway (MAG) of PMIPv6 is used. For convenience of reference, this document generally refers to these access nodes as mobile multicast agent. They are specifically referred to as Multicast Home Agent (MHA) on the home network and Multicast Foreign Agent (MFA) on the foreign network. 3.2. Address Configuration and Registration Process The receiver mobility multicast scheme has no restrictions on the address types adopted by the mobile receiver and the access network. They could be IPv4-only, IPv6-only or dual stack. To use which type of addresses depends on the policy of the provider or on the customer's service profile. If MIPv4 or (DS)MIPv6 is used, the mobile receiver uses home address on home network and Care-of Address (CoA) on the foreign network. The acquisition and configuration of the addresses and the binding of them on the MHA should share the same procedures as those adopted in the MIP protocols. The CoA can be generated by MFA advertisement or by external assignment method (such as DHCP [8][9] and etc.), with more detailed explanation in [1][2]. After obtaining the CoA, the receiver should register on the MHA to establish binding relationship between its CoA and home address. PMIPv6 has the differences that the address configured on the foreign network is home-network prefixed and registration binding operations of the receiver take place between MFA and MHA not involving the MN. Liu. Expires December 14, 2009 [Page 6] Internet-Draft Multicast Receiver Mobility June 2009 MIP protocols (MIPv4, MIPv6 or DSMIPv6, PMIPv6 and etc.) can be used to implement the registration and binding. The related registration request and registration acknowledgment messages (Registration Request and Registration Reply for MIPv4, Binding Update and Binding Acknowledgement for (DS)MIPv6, and Proxy Binding Update and Proxy Binding Acknowledgement for PMIPv6) could be transmitted via MFA or directly between the receiver and the MHA, depending on different MIP protocol adopted. These messages can be extended to carry the option or flag for mobile multicast capability negotiation as they are transmitted. 3.3. Tunnel Mechanism Considerations In tunnel mechanism, the MHA will take the duty of group membership management and multicast tree joining. All the traffic will be sent or received through the tunnel to or from the MHA. When MIPv4 is used, the endpoints of the tunnel are the MHA and the CoA of the receiver. If the CoA is registered through the MFA, then MFA terminates the tunnel, or if the CoA is registered directly with the MHA (in the co-located mode), then the receiver itself terminates the tunnel. In other cases, the tunnel endpoints are generally the MHA and the receiver for (DS)MIPv6, and are the MHA and MFA for PMIPv6. Thus for different MIP protocols, the endpoint of the tunnel on the home network is the MHA, and the endpoint of the tunnel on the foreign network can be either the MFA or the receiver. The tunnel could be statically created and deleted, or could be established dynamically when needed. The encapsulation type could be IP-in-IP, GRE and minimal encapsulation as discussed in [1][2][3]. The address type of the outer and inner IP address could be of IPv4 or IPv6 according to the address type adopted by the receiver and the provider network. 3.4. Group Membership Management The mobile receiver uses group management protocol IGMP (for IPv4) [10][11] and MLD (for IPv6) [12][13] to join a multicast group, which could be an ASM group or SSM group. Among the various versions of the protocol, IGMPv3, MLDv2, and their simplified versions LW-IGMPv3 and LW-MLDv2 [24] are suggested to be used because they support source-specific group join mode, which is useful in efficient multicast provision. Besides, the protocols also provide the capability to implement explicit tracking (not Liu. Expires December 14, 2009 [Page 7] Internet-Draft Multicast Receiver Mobility June 2009 available in their early versions), which helps improve fast leave capability. Normal IGMP or MLD procedure is used for receiver to send group report and for mobile multicast agent to query the receiver. For tunnel mechanism, these reports and queries are sent through the tunnel between the MHA and the MFA or between the MHA and the receiver. For multicast routing optimization, these messages will be exchanged between the MFA and the receiver directly. The IGMP and MLD packet should be destined to link-local address and their TTL field should be set to 1. The setting of the destination address of the query and report should follow the rules prescribed in IGMP or MLD protocols. 3.5. Multicast Tree Construction and Data Forwarding If the receiver is on the home network, or it is on the foreign network while using the tunnel mechanism, then MHA will engage in the construction of the multicast tree. The MHA exchanges multicast routing packets with upstream intermediate multicast routers with normal multicast routing procedures. The multicast routing protocol could be of any type mentioned in section 2. After receiving the multicast data, if the receiver is on the home network, the MHA will deliver them to the receiver directly. If the receiver is on the foreign network, the MHA will encapsulate them in the tunnel and send them to the tunnel endpoint of the foreign network, which may be MFA or receiver itself according to the kind of the MIP protocol adopted. In the former case, the MFA will de- capsulate the tunneled data and forward them to the receiver. If the receiver is on the foreign network while using multicast route optimization, then MFA will engage in the construction of the multicast tree. The MFA will exchange multicast routing packets with upstream intermediate multicast routers on the foreign network. After receiving the multicast data, the MFA will deliver them to the receiver directly. As the summary of the features illustrated above, an example of multicast receiver mobility architecture is shown in figure 1. The lines between the blocks are bidirectional. With the assumption that MHA coexists with multicast Last hop, the multicast routing protocol is running among multicast source, intermediate routers (omitted in the figure), and MHA, MFA1, MFA2 and MFA3 entities. IGMP/MLD message should be exchanged between the receivers and the Liu. Expires December 14, 2009 [Page 8] Internet-Draft Multicast Receiver Mobility June 2009 multicast last hop (MHA and MFAs) and will be transmitted through tunnel if tunnel mechanism is used. Receivers R1, R2 and R3 use multicast tree constructed on home network to forwarding multicast traffic. They correspond respectively to the cases when the receiver is on home network (MIP registration is not required), when MIP registration takes place directly between the receiver and the MHA (MIPv6, DSMIPv6 or Co- located MIPv4), and when MIP registration involves the MFA's processing (PMIPv6 or Foreign-Agent-Advertised MIPv4). R4 and R5 utilize optimal multicast routing with the multicast tree constructed on foreign network through MFA2 and MFA3. The difference between R4 and R5 cases lies in which kind of MIP protocol is supported. For R4 the MIP is running via MFA2 (PMIPv6 or Foreign- Agent-Advertised MIPv4) and for R5 MFA3 does not involve the MIP signaling processing (MIPv6, DSMIPv6 or Co-located MIPv4). The MIP in brackets for R3 and R4 cases indicates that the MIP between the receiver and the MFA is optionally supported, corresponding to PMIPv6 (not supported) and Foreign-Agent mode MIPv4 (supported) respectively. Multicast routing +------+ protocol +-----+ IGMP/MLD +----+ |source| -------... -------- | MHA |----------| R1 | +------+ / +-----+ \ +----+ multicast| \multicast / / | \ routing : :routing / / |MIP& \MIP&tunneled protocol: :protocol /MIP / |Tunneled \IGMP/MLD | \ / / |IGMP/MLD \ +----+ +----+ / +-----+ +----+ |MFA3| |MFA2| | | MFA1| | R2 | +----+ +----+ | +-----+ +----+ | | | | IGMP/MLD| IGMP/MLD|(MIP) | |IGMP/MLD(MIP) | | | | +----+ +----+ | +----+ | R5 | | R4 | | | R3 | +----+ +----+ MIP| +----+ | | |--------------------| Figure 1 Protocol Packets Exchanged in Multirem Architecture Liu. Expires December 14, 2009 [Page 9] Internet-Draft Multicast Receiver Mobility June 2009 The multicast data forwarding flow is shown in figure 2. R1 is on home network thus is expected to receive native multicast data from MHA, which is completely the same as that of the fixed network multicasting. For tunnel mechanism, the data is forwarded from source to MHA and then to R2 or R3. R2 uses (DS)MIPv6 or Co-located mode MIPv4 for registration and R3 uses PMIPv6 or Foreign-Agent mode MIPv4. R4 receives multicast data with optimal multicast routing regardless of the MIP protocols adopted. 1)multicast data arrive from source to MHA via multicast tree constructed 2)From MHA +------+ on home network +-----+ to R1 +----+ |source|------//--------> | MHA | -------> | R1 | +------+ +-----+ +----+ 6)multicast | | \ data arrive : 4)through Tunnel | \3) through tunnel to MFA2 via | from MHA to MFA1| \ from MHA to R2 tree on \|/ \|/ _\| foreign +----+ +-----+ +----+ network |MFA2| | MFA1| | R2 | +----+ +-----+ +----+ | | 7)From MFA2| | to R4 | 5)From MFA1 | \|/ to R3 \|/ +----+ +----+ | R4 | | R3 | +----+ +----+ Figure 2 Multicast Data Forwarding Diagram 3.6. Handover Considerations The receiver could be in three states during handover. Firstly the receiver did not join any group and is not receiving any multicast data, then the multicast process is not needed and unicast MIP is Liu. Expires December 14, 2009 [Page 10] Internet-Draft Multicast Receiver Mobility June 2009 used to make tracking of the receiver. Secondly, the receiver may previously have not received from any group, but subscribes to a group during the handover. Because generally there is no real-time requirement when the receiver initially makes group subscription, the process should be the same with that without handover. In the last case, the receiver continues multicast receiving during handover, which is much more prone to packet loss, because the receiver needs to make connection to the new network, to undergo the configuration, registration and binding of its new address, and to wait the multicast delivery on the new network. The above series of processes require a specific period of time. If the receiver fails to keep the connection to the previous link before the new data path is established, the packet loss will be inevitable. This section only discusses the third case about how to smooth the handover when receiver is in the receiving state. FMIP [14][15] improves the handover performance by shortening the initial configuration time to accelerate handover process and by establishing supplement data tunnel between the previous and new access routers to reduce packet loss. For multicast reception, a similar process may also be needed because of the high-throughput feature in multicast data transmission. For example, the address configuration delay could be reduced by advertising new network address by previous MFA (pMFA) as described in FMIP protocol. 3.6.1 Handover in Tunnel mechanism The registration and binding process is initiated after the receiver acquires its new address on the foreign network and thereafter the multicast data should be delivered by the MHA to the new foreign network quickly. Because the MHA should have knowledge of multicast reception state of the receiver on the new network to decide whether to send traffic to the new network or not, the group membership information on the new network needs to be delivered to the MHA as soon as possible. MIPv6 has the requirement that ''the mobile mode must not tunnel group control packets until (1) the mobile node has a binding in place at the home agent, and (2) the latter sends at least one multicast group membership control packet via the tunnel'' [2]. If this requirement is strictly followed in MIP protocols, the receiver should wait for the registration acknowledgment and the group query before sending its group report, which means the MHA after registration immediately sends group query through the new tunnel. To minimize the time consumed by this process, the group query of the MHA could be bound together with the registration acknowledgment Liu. Expires December 14, 2009 [Page 11] Internet-Draft Multicast Receiver Mobility June 2009 message with the latter extended to carry the information provided by a query to the receiver. The method has the advantage of reduction of process time and number of packets. If above requirement is not strictly followed and if the receiver is permitted to send group report even before the completion of the registration and the arriving of the query, it is also possible to combine the group report with the registration request message to shorten the multicast delivery. In this case, the registration request message could be extended to carry the necessary information provided by the report to the MHA [21][22]. 3.6.2 Handover in Route Optimization For the routing optimization mechanism, after the registration, the new MFA (nMFA) will take the duty of data forwarding based on the optimal multicast routing on the foreign network. If formerly there isn't any multicast forwarding path on the nMFA for this group, the latency introduced by the registration plus the construction of new multicast tree branches could be considerable. In different scenarios there may be different measures to shorten this handover delay. For example, if the MHA currently is just on the multicast tree for this group, it can deliver the multicast traffic to the MFA or the receiver immediately after the completion of registration process, even if the new access network uses multicast optimization. After receiving the new optimal multicast data, the reception from the tunneled data should be terminated. This process is similar to the handover of tunnel mechanism and to quicken this process, combination of the registration messages with group query or report can also be adopted, as illustrated in section 3.6.1. In some cases if the MFA is endowed with greater right, the new MFA could join multicast tree immediately after connecting to the receiver, not waiting for the registration acknowledgement of the MHA. If the multicast data arrives before the returning of the registration acknowledgment, the MFA should buffer the traffic and wait for the registration acknowledgement of MHA to trigger the multicast forwarding. 3.6.3 Hybrid Handover There should be no limitation that a uniform mechanism must be taken when the receiver is moving from an access network to another. That Liu. Expires December 14, 2009 [Page 12] Internet-Draft Multicast Receiver Mobility June 2009 is, the receiver could use tunnel and then use optimal multicast routing to receive multicast traffic and vice versa. During this hybrid network handover, if route optimization is adopted in the new access network, the receiver takes the process of registering on the MHA, sending group report towards the nMFA, and receiving the new multicast data from the nMFA. If tunnel mechanism is adopted in the new network, the receiver should follow the procedures of registering and sending group reporting on the MHA, receiving the multicast traffic from the new tunnel. The detailed process of both cases of hybrid handover should be the same as those described in 3.6.1 and 3.6.2. 3.6.4 FMIP Tunnel During Handover FMIP [14][15] provides another measure to avoid or reduce packet loss during handover. Because the data is still available on the previous MFA (pMFA) and the receiver is or will be connectable on the new MFA (nMFA), the tunnel between these two MFAs can be used to deliver data through the tunnel from the pMFA to the nMFA and then to the receiver. Here steps of predictive mode multicast FMIP are used to demonstrate the process. After the detection of the new network, the receiver could solicit its nCoA and nMFA information through sending RtSolPr to and receiving PrRtAdv from pMFA. Then the receiver sends FBU message to pMFA to request the multicast tunnel. The pMFA and nMFA exchange HI and HACK messages and after FBack sent by the pMFA the multicast data is tunneled from the pMFA to the nMFA. Finally the receiver triggers the reception of the data from the nMFA by sending UNA message. FMIP is a transitional solution to optimizing handover process. It does not engage in the registration of the mobile receiver and could be deployed with all kinds of MIP protocols (i.e. MIPv4, MIPv6 or DSMIPv6, PMIPv6 [25] and etc.) with multicast capability support. It is possible that group membership information could be carried in extended FMIP messages to trigger multicast reception through FMIP tunnel as illustrated in [26]. 3.6.5 Termination of Duplicate Multicast Traffic In different handover scenarios mentioned in previous sections, the receiver is possibly receiving at the same time from both the new and previous network when it is connected to both links and possibly Liu. Expires December 14, 2009 [Page 13] Internet-Draft Multicast Receiver Mobility June 2009 receives redundant traffic. Normally at this time the old path should be torn down as quickly as possible to reduce unnecessary traffic. It is possible to let the previous forwarding entity to wait for a specific period of time before stopping the previous traffic. But sometimes this predetermined time interval might not meet the complicated handover situations. Further, if the previous and new forwarders do not coexist (e.g. in optimal multicast routing handover cases), it is impossible for the previous forwarder to know the exact time when the new traffic arrives at the receiver. One solution to this is to inform the previous forwarder the ceasing of data delivery by some kind of control message. Even though a new message particular for this purpose could be defined, it is also possible to make use of an IGMP/MLD group leave packet. This IGMP/MLD packet to terminate redundant multicast traffic is different from the normal IGMP Leave or MLD Done message for their purpose is to inform the end of redundant traffic rather than to de- subscribe from the group. If it is possible, the source address of this IGMP/MLD control packet could be set to the receiver's previous network address to distinguish it from a normal group de- subscription leave packet. On receiving this control message, the previous forwarding entity should stop forwarding multicast traffic and possibly take other procedures such as pruning from the multicast tree if there is no other multicast receiver attached to its link. 3.6.6 Moving Back and Forth during Handover When a receiver is moving back and forth during handover, it may connect an access node then disconnect it, or may disconnect and then reconnect it, described as ''ping-pong mobility'' in [18]. For the latter case, when the disconnection occurs, the access node may prune the multicast forwarding path. If after a while, when the receiver moves back and reconnects to the access node, the multicast forwarding path has to be re-established, with additional signaling delay. To overcome this shortcoming, the access nodes during handover could choose to preserve for a specified period of time the forwarding and other related states for the receiver even though the receiver is out of reach. If within this time interval the receiver moves back into the access node's range, the multicast data could be delivered to the receiver quickly. For tunnel mechanism, the forwarding states should be preserved by the MHA and for route optimization Liu. Expires December 14, 2009 [Page 14] Internet-Draft Multicast Receiver Mobility June 2009 they should be preserved by MFA. This measure can be used to improve the multicast handover performance but can be deployed by both the unicast and multicast applications. 3.7. Authentication and Accounting The authentication is used to check the validity of the message originator in multicast mobility architecture. The authentication can be carried out anytime and anywhere and on any entities depending on the policy deployed by the network providers. The provider according to the trust level of the entities determines what kind of security mechanism should be put on these entities when they exchange their messages. The authentication probably happens when a receiver initially connects to the access nodes of home or foreign network, when the receiver registering its binding on its MHA, when the receiver registers on its MFA, or when the pMFA and nMFA decide to use the tunnel for fast handover. There should be no restrictions on the authentication mechanism adopted. They could be taken by other protocols or could be carried in the messages within multicast mobility architecture, which are not discussed in this document. The accounting of multicast receiver could be implemented out-band of multicast data transfer. The MHA and MFA as the direct data forwarder to the receiver could take the duty of collecting accounting data and could send them actively to the accounting server or other network entities, or passively in response of the queries. The implementation methods should depend on the deployment policy of the provider and are not discussed within this document. 4. Considerations for Different MIP Protocols 4.1. MIPv4 MIPv4 defines two different communication modes according to whether the CoA is assigned by the foreign agent or by other external mechanism. They are discussed in section 4.1.1 and 4.1.2. 4.1.1 When CoA advertised by foreign agent In this mode an entity of foreign agent involves in the MIPv4 signaling procedures and it should be the MFA in multicast receiver mobility architecture. The receiver takes normal fixed-network multicast procedures on home network. On foreign network, after the receiver obtains its CoA, it Liu. Expires December 14, 2009 [Page 15] Internet-Draft Multicast Receiver Mobility June 2009 registers through the MFA the binding of this CoA on MHA by MIPv4 signaling. If tunneling is used, the MFA encapsulates the receiver's IGMP report and tunnels it to the MHA and the MHA queries periodically the group membership of the receiver through the tunnel to the MFA. The MHA on receiving the report joins the multicast tree on the home network and after receiving the multicast data sends them through the tunnel towards the MFA. The MFA decapsulates the queries and the multicast data and forwards them to the receiver. The endpoints of the tunnel are MHA and MFA, with outer layer addresses set to the interface addresses of the MHA and the home address of the receiver. The inner sources of the report and query should be respectively the home address of the receiver and interface address of MHA. The inner destination address of the report and query should be set as the IGMP protocols describe. If optimal multicast is used, the IGMP group reports will be processed and IGMP queries will be sent by the MFA (if it is the last-hop), which will join the multicast tree on the foreign network. After receiving the multicast data, the MFA forwards them to the receiver. The receiver and the MFAs can use IPv4 version of FMIP [14] and its extension to facilitate the fast handover, as described in section 3.6.4. 4.1.2 Co-located CoA In this mode the receiver and the home agent communicate directly and there is no such an entity as the foreign agent. Thus the access node on the foreign network is regarded as the MFA in the multicast mobility. The co-located CoA is configured by other external mechanism such as DHCP. The registration of this CoA is directly between the receiver and the MHA by MIPv4 signaling. For tunnel mechanism, after the registration and binding, if the receiver wants to subscribe a multicast group, it sends the IGMP report directly to the MHA through the tunnel to the MHA. The MHA joins the multicast tree on the home network and after receiving the multicast data, tunnels them directly to the receiver. The endpoints of the tunnel are MHA and the receiver, with outer layer addresses set to the interface addresses of the MHA and the CoA of the receiver. The inner source of the report and query should be the home address of the receiver and interface address of Liu. Expires December 14, 2009 [Page 16] Internet-Draft Multicast Receiver Mobility June 2009 MHA. The inner destination address of the report and query should be set as the IGMP protocols describe. If optimal multicast route is used, the access node on the foreign network should act as MFA and should be engaged in the multicast tree construction on the foreign network. This access node after receiving the multicast data, will deliver them to the receiver. The receiver should use its CoA when communicating with its MFA if MFA is ignorant of the receiver's home address. In this case the address setting rule should be the same as that of fixed network multicast. The receiver and the MFAs can use IPv4 version of FMIP [14] and its extension to facilitate the fast handover, as described in section 3.6.4. 4.2. MIPv6 and DSMIPv6 MIPv6 resembles the co-located mode of MIPv4 for the receiver communicates directly with the home agent without the signaling participation of the access node on the foreign network, as described in section 4.1.2. The receiver use traditional IPv6 address configuration method (stateless or stateful) to obtain the CoA address on foreign network and use MIPv6 signaling to make the registration and binding between the CoA and home address on the home agent. Both tunnel and optimal multicast routing can be used and the address setting method for group membership message and multicast data should follow the principles given in MIPv6 and MLD protocols. FMIPv6 [15] is used and may be extended implementing multicast fast handovers as illustrated in section 3.6.4. DSMIPv6 supplements MIPv6 with accessing of IPv4 public and private foreign networks besides the IPv6 one. The basic communication mechanism is the same as that of MIPv6. For DSMIPv6 the binding of home and CoA addresses are established for both IPv6 and IPv4 types and the tunnel should be set according to the types of access network. In tunnel mechanism, the inner group membership management should use MLD protocol. The address setting of tunneled packet should follow the rules given by DSMIPv6 and MLD protocols. If optimal multicast routing is used, the receiver after registration sends group report to MFA. It is reasonable that MLD will be used on IPv6 foreign network and IGMP shall be used on IPv4 network between the receiver and the MFA. Liu. Expires December 14, 2009 [Page 17] Internet-Draft Multicast Receiver Mobility June 2009 If the handover takes place between IPv6 foreign networks then is FMIPv6 [15] or its extension should be used for multicast fast handover. While for IPv4 networks the FMIPv4 [14] could be used. 4.3. PMIPv6 In PMIPv6, the receiver itself does not engage in the PMIP signaling and LMA and MAG are respectively the MHA and the MFA counterparts in the receiver mobile multicast. Besides, there is no permanent home address and the receiver's address obtained on the foreign network is home-network prefixed. The MAG has a proxy CoA address to communicate by bidirectional tunnel with the LMA. The receiver obtains its CoA at the current point of attachment and then the MAG will register the binding relationship for it on the LMA by PMIP signaling. Even if PMIP only defines tunnel mechanism, it is also possible to use multicast route optimization. In tunnel mechanism, if the receiver wants to join a multicast group, it sends group report towards MAG and the MAG will encapsulate the MLD report and tunnel it to the LMA. The LMA queries the receiver through the tunnel from LMA to MAG and LMA initiates the tree join operation. After receiving the multicast data, the LMA tunnels them to the MAG and MAG will decapsulate and forward them to the receiver. The outer layer addresses of tunneled packet should be set to the Proxy-CoA of MAG and the interface address of LMA. When the receiver sends the MLD report, its source address should be set to the home-network prefixed address of the receiver. The source address of the query should be the address of the LMA. The destination addresses of the report and the query are set according to MLD protocols. If optimal multicast routing is used, the MAG after receiving the group report will initiate the multicast tree construction on the foreign network. After receiving the multicast data, the MAG will deliver them to the receiver. The receiver uses home-linked address when communicating with the MAG. The address setting rule for MLD messages and the multicast data should be the same as that of fixed- network multicast. Fast handover for PMIPv6 (e.g FPMIPv6 [25]) or its extension can be used to reduce possible multicast data loss during handover. Liu. Expires December 14, 2009 [Page 18] Internet-Draft Multicast Receiver Mobility June 2009 5. Security Considerations The security mechanism particular for MultiRem will be considered in the later version of the draft. 6. Acknowledgments The author appreciates multimob mail list participants for their contributions to this document. Special thanks should be given to Behcet Sarikaya for his valuable comments for it. 7. References 7.1. Normative References [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [6] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", RFC 4875, May 2007. [7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC4605, August 2006. [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [9] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Liu. Expires December 14, 2009 [Page 19] Internet-Draft Multicast Receiver Mobility June 2009 [10] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002 [12] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [13] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2(MLDv2) for IPv6", RFC 3810, June 2004. [14] R. Koodli and C. Perkins, " Mobile IPv4 Fast Handovers", RFC 4988, October 2007 [15] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 5268, October 2007. 7.2. Informative References [16] H. Soliman, "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-10.txt, April 7, 2009 [17] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004. [18] Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", draft-deng-multimob- pmip6-requirement-00.txt (work in progress), November 2007. [19] F. Xia, B. Sarikaya, "Hybrid Subscription for Multicast Reciever Mobility in MIPv6", draft-xia-multimob-hybrid-00.txt (work in progress), November 2007 [20] Hong-ke Zhang, Jian-feng Guan, Hua-chun Zhou, Ying Zhu, "Multicast Routing in Proxy Mobile IPv6", draft-zhang-netlmm-pmipv6- mcast-00.txt(work in progress), September 2008 [21] H. Asaeda, P. Seite, J. Xia, "PMIPv6 Extensions for Multicast", draft-asaeda-multimob-pmip6-extension-00(work in progress), October 2008 [22] Y. K. Zhao and P. Seite, "The Solution for Pmipv6 Multicast Service", draft-zhao-multimob-pmip6-solution-02.txt, October 2008 Liu. Expires December 14, 2009 [Page 20] Internet-Draft Multicast Receiver Mobility June 2009 [23] I. Minei, K., Kompella, I. Wijnands, and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp- p2mp-05.txt, May 2008. [24] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2 Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-03.txt (work in progress), June 2008 [25] H. Yokota, K. Chowdhury, B. Patil, F. Xia, " Fast Handovers for Proxy Mobile IPv6", draft-ietf-mipshop-pfmipv6-04.txt (work in progress), May 2009 [26] Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast Handover", draft-xia-mipshop-fmip-multicast-01 (work in progress), March 2007 Authors' Addresses Hui Liu Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: liuhui47967@huawei.com Liu. Expires December 14, 2009 [Page 21]