Network Working Group Y K. ZHAO Internet-Draft Individual Consultant Intended status: Standards Track P. Seite Expires: January 14, 2010 France Telecom July 13, 2009 The Solution for Pmipv6 Multicast Service draft-zhao-multimob-pmip6-solution-03.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 January 14, 2010. 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. ZHAO & Seite Expires January 14, 2010 [Page 1] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 Abstract To mobility scenario, multicast service is a valuable feature to those mobile customers. We need to consider how to integrate current multicast service in PMIPv6 domain. This draft will introduce this kind of solution about proxy mobile multicast. It explains the system solution and framework about how to provide the proxy mobile multicast system. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Initiation of proxy mobile multicast service . . . . . . . 7 4.1.1. Triggered from the network . . . . . . . . . . . . . . 7 4.1.2. Triggered by the mobile node . . . . . . . . . . . . . 10 4.2. Proxy mobile multicast service during handover . . . . . . 12 4.2.1. Proxy mobile multicast service during normal handover . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Proxy mobile multicast service during fast handover . 13 4.3. Termination of proxy mobile multicast service . . . . . . 13 4.3.1. Terminated from network . . . . . . . . . . . . . . . 13 4.3.2. Terminated by mobile node . . . . . . . . . . . . . . 13 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 15 5.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 15 5.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 15 5.3. Operated as the MLDv2 listener . . . . . . . . . . . . . . 15 6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16 6.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 16 6.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 16 7. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 17 7.1. Operation without the MLDv2 . . . . . . . . . . . . . . . 17 8. Protocol compatible considerations . . . . . . . . . . . . . . 18 8.1. Negotiation during handover . . . . . . . . . . . . . . . 18 9. Protocol considerations . . . . . . . . . . . . . . . . . . . 19 9.1. PMIPv6 messages extension . . . . . . . . . . . . . . . . 19 9.2. Context definition during handover . . . . . . . . . . . . 19 9.3. Protocol configuration variables . . . . . . . . . . . . . 19 9.4. MTU consideration . . . . . . . . . . . . . . . . . . . . 19 9.5. IPv4-IPv6 co-existence . . . . . . . . . . . . . . . . . . 19 9.6. IPv4 considerations . . . . . . . . . . . . . . . . . . . 19 9.7. Source of Multicast request . . . . . . . . . . . . . . . 20 9.8. Handling of joining local multicast group . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 ZHAO & Seite Expires January 14, 2010 [Page 2] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 12. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 ZHAO & Seite Expires January 14, 2010 [Page 3] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 1. Requirements notation 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]. ZHAO & Seite Expires January 14, 2010 [Page 4] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 2. Introduction Multicast is a very important fundamental service. It can be applied to support many different applications, such as IPTV,MBMS etc. Meanwhile, Proxy mobile IP is a technology used to be provided for the hosts that don't need MIP stack installed to make mobility management. So we need to support multicast service for hosts using the proxy mobile IP protocol. In this draft, we will try to introduce how to meet those requirements and make PMIPv6 supply multicast. ZHAO & Seite Expires January 14, 2010 [Page 5] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 3. Conventions & Terminology Broadcast Services: It may be subscription based and the system should support means to measuring subscriber usage for billing purposed. Dynamic Multicast Service: It is an kind of multicast service in which the mobile node needs to manage the multicast group it receives by itself. In this case, the MAG or LMA keeps track of subscribers using the service, the service is initiated by users's request and is terminated by the request of the mobile node or when no user is using the service. Static Multicast Service: It is an kind of multicast service in which the transmission of content does not dynamically change based on the subscriber usage and the network may or may not be aware of subcribers' using the service at a given time. Mobile Node: It is the ultimate terminal receives the multicast service provided by network. But it can run the MLDv2[RFC3810] to communicate with network or managed by network directly. LMA: It is the standard entity defined as [RFC5213]. MAG: It is the standard entity defined as [RFC5213]. MLDv2 Listener: It is the standard entity defined as [RFC3810]. MLDv2 Proxy: It is the standard entity defined as [RFC4605]. MLDv2 Router: It is the standard entity defined as [RFC3810]. ZHAO & Seite Expires January 14, 2010 [Page 6] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 4. Overview To proxy mobile multicast protocol, we should reuse the existing mature protocols related to pmip and multicast as more as we can. And we shall keep the requirements of the mobile node as simple as we can. So this draft keeps consistent with PMIPv6[RFC5213]. The MAG can represent the MN to establish and maintain the multicast service based on existing info provided by pre-configured, policy store, context transfer or even MN's request. And the multicast service can be terminated by MN, the MAG or the source of multicast service itself. 4.1. Initiation of proxy mobile multicast service The mobile multicast service in PMIPv6[RFC5213] domain can be initiated by either network or the mobile node. When it is initiated by the mobile node, the MN will need to run MLDv2[RFC3810] with the MAG to triggered the MAG to start to establish the multicast service. In another case, from those profiles or some pre-configured materials, the MAG can just start the multicast service representing the Mobile node in the absense of MLDv2[RFC3810] sent from the Mobile node. But be noted that, even in this case, the mobile node still can ask for joining some multicast groups, and the MAG should deal with it correctly. 4.1.1. Triggered from the network 4.1.1.1. In the absence of the MLDv2 In some multicast architectures, the MAG may initiate multicast subscription. When this happens, the MAG initiates multicast subscription and MN sends the MLDv2[RFC3810] message to avoid the packet to be filtered by the OS; but those MLDv2[RFC3810] message is not sent to the network. And if implementation supports, MN can also don't send MLDv2[RFC3810] out to ask for joining those related multicast groups. When the MN just attaches to a MAG, the MAG gets the MN's profile and finds some pre-configured multicast services which need to be established, then it will request the LMA to provide the respective service. At this time, the methods which are used to communicate the LMA with the MAG are either PMIP signals or MLDv2[RFC3810] report messages etc. The LMA will check those requests and make the decision based on its acknowledges about it. The process is as the following: ZHAO & Seite Expires January 14, 2010 [Page 7] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 _________ ____________ ........ ....... ...... | Policy| | Multicast| | MN | | MAG | |LMA | | Store | | Source | `'|''' '`'|''' `'|'' `'''|''' `''''|'''' |1)Attachment | | | |<--------->|2)Entry network authorization | | | |------------------------------->| | | |<-------------------------------| | | | 3)Retrieve MN's profile | | | | ( including multicast info) | | | ........................ | | | | | 4)Based on profile | | | | | | Decided if need to | | | | | | Join multicast group | | | | | `''''''''''''''''''''' | | | | | | | | | | 5)PBA | | | | | &Multicast joining | | | | |---------------------->|________|__________ | | | |6)possible multicast | | | | 7)PBA&Multicast |authorization progress| | | |<----------------------|''''''''''''''''''' | | | subscription result | | | | | | 8)Multicast joining | | | |--------+----------->| |9)Multicast| 9)Multicast traffic | 9)Multicast traffic | |<----------|<----------------------|<--------------------| Figure 1: Network-Initiated multicast service establish progress without the MLDv2 1. The Mobile node attachs to the network. 2. The attachment of MN triggers the MAG to make network entry progress for the MN. the MAG can contact with policy store to do authentication and authorization for this MN as description in PMIPv6[RFC5213]. 3. Policy store returns back with those related profiles for this MN to the MAG. 4. Based on the profile, the MAG decides if it necessary to do PMIP Registration and join in some multicast groups specified by the profile. 5. The MAG sends PMIPv6[RFC5213] Binding Updates and/or multicast message (For join some multicast groups) to the LMA. Here the ZHAO & Seite Expires January 14, 2010 [Page 8] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 multicast message can be integrated with PMIPv6[RFC5213] Binding Update message, or also MLDv2[RFC3810] report message etc. 6. After receiving PBU, the LMA will do as described in PMIPv6[RFC5213] and necessary authentication and authorization for the multicast service of that MN. 7. After that, it returns the result of PMIPv6[RFC5213] registration and multicast subscription. It veries depending on the specific protocol used by the messages. 8. The MAG adds new multicast group or forwards related traffics to the MN. 9. The multicast traffics can be forwarded to the MN. Notes: If the requested multicast resource can't be assigned or need to be denied, the LMA will inform the MAG via PBA (if PBU is used to indicate multicast service), or others. In addition, when the local routing for multicast is enabled, the MAG should send multicast subscription directly to its near multicast router but not the LMA. And the reverse multicast traffics can be received by the MAG directly. In this case, the MAG plays as a MLD proxy[RFC4605] or MLDv2[RFC3810] listener if no any MLDv2[RFC3810] messages need to be run between the MAG and the mobile node. Here, we don't request the mobile node to send any MLDv2[RFC3810] messages, but if the mobile node would like to send them, the MAG that in MLDv2[RFC3810] proxy/router mode should process them normally, and combine them with the profile got from policy store to make final decision about such as subscription, joining, leaving etc. 4.1.1.2. With the MLDv2 Except the above progress, the mobile multicast service can also be initiated from network with MLDv2[RFC3810] protocol running between the MAG and mobile node. In this case, the MAG retrieves the multicast services from profile store after a mobile node attach to the PMIPv6[RFC5213] domain. And then if it finds some multicast services need to be initiated or in the later , after triggered by the LMA, it can just send the MLDv2[RFC3810] query message to ask if the mobile node would like to receive some multicast services. The message flow is as the following: ZHAO & Seite Expires January 14, 2010 [Page 9] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 _________ ____________ ........ ....... ...... | Policy| | Multicast| | MN | | MAG | |LMA | | Store | | Source | `'|''' '`'|''' `'|'' `'''|''' `''''|'''' |1)Attachment | | | |<--------->|2)Entry network authorization | | | |------------------------------->| | |4)MLDv2 Query<------------------------------| | |<----------| 3)Retrieve MN's profile | | |5)MLDv2 Report ( including multicast info) | | |----------->................. | | | | | 6)Based on profile | | | | | | Decided if need to | | | | | | Join multicast group | | | | | `''''''''''''''''''''' | | | | | | | | | | 7)PBA | | | | | &Multicast joining | | | | |---------------------->|________|__________ | | | |8)possible multicast | | | | 9)PBA&Multicast |authorization progress| | | |<----------------------|''''''''''''''''''' | | | subscription result | | | | | |10)Multicast joining | | | |--------+----------->| |11)Multicast 11)Multicast traffic |11)Multicast traffic | |<----------|<----------------------|<--------------------| | | | | | Figure 2: Network-Initiated multicast service establish progress with MLDv2 4.1.2. Triggered by the mobile node ZHAO & Seite Expires January 14, 2010 [Page 10] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 _________ ____________ ........ ....... ...... | Policy| | Multicast| | MN | | MAG | |LMA | | Store | | Source | `'|''' '`'|''' `'|'' `'''|''' `''''|'''' |1)Attachment | | | |<--------->|2)Entry network authorization | | | |------------------------------->| | | |<-------------------------------| | | | 3)Retrieve MN's profile | | |4)MLDv2 Report ( including multicast info) | | |----------->................. | | | | | 5)Based on profile | | | | | | Decided if need to | | | | | | Join multicast group | | | | | `''''''''''''''''''''' | | | | | | | | | | 6)PBA | | | | | &Multicast joining | | | | |---------------------->|________|__________ | | | |7)possible multicast | | | | 8)PBA&Multicast |authorization progress| | | |<----------------------|''''''''''''''''''' | | | subscription result | | | | | |9 )Multicast joining | | | |--------+----------->| |10)Multicast 10)Multicast traffic |10)Multicast traffic | |<----------|<----------------------|<--------------------| | | | | | Figure 3: mobile node-Initiated multicast service establish progress If the mobile node knows some multicast groups should be joined, it will send the MLDv2[RFC3810] report to the MAG about those target multicast groups which it wants to join in. In addition, if the mobile node receives the MLDv2[RFC3810] query from the MAG, it will also make response by sending the MLDv2[RFC3810] report about those multicast groups which it wants to get. After receiving MLDv2[RFC3810] report which is sent from MN, the MAG will inform the LMA/Multicast router. And before this, the MAG will do some related authorization or authentication to check the request. While the MAG don't inform the LMA/Multicast router about every request from MNs, it just inform the LMA about those the ones which are the first comers to some one multicast groups. ZHAO & Seite Expires January 14, 2010 [Page 11] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 4.2. Proxy mobile multicast service during handover No matter what the initiator is (network or mobile node), both cases have the common handover process. 4.2.1. Proxy mobile multicast service during normal handover Generally, when there is not any optimization, the handover will involve of MNs by running the MLDv2[RFC3810] protocol with new MAG to receive the related on-going multicast services. ......... ............ ........ ....... ,______ ...... | Policy| | Multicast| | MN | |p-MAG| |n-MAG| |LMA | | Store | | Source | `'|''' '`'| | '|'' `'''|''' `''''|'''' |1)Attaching to new MAG | | | |------------------->| | | | | | '2)Request MN's profile | | | | +--------------+------->+ | |4)MLDv2 query |3)Response with MN's profile | |<-------------------|<----------------------| | |5)MLDv2 report | (multicast info) | | |------------------->| | | | ,_____|____________ | | | | | |6)Checking profile| | | | | | |parsing multicast | | | | | | |related info and | | | | | | |decide multicast | | | | | | |group management | | | | | | |action | | | | | | '`''''''''''''''''' | | | | | |7)multicast | | | | |------------->| 8)multicast group | | | | subscription|<===================>| | | |9)multicast | management | | | |<-------------| | | | | | subscription response | | | | | | | | Figure 4: Proxy mobile multicast service during normal handover ZHAO & Seite Expires January 14, 2010 [Page 12] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 4.2.2. Proxy mobile multicast service during fast handover But, for performance consideration, the method of context transfer is expected to provide necessary multicast information during handover progress. And if it is necessary, a 3-rd party policy store is required to be used to provide necessary information no matter whether context transfer will be used or not. ......... ............ ........ ,______ ...... | Policy| | Multicast| |p-MAG | |n-MAG| |LMA | | Store | | Source | `'|''' | '|'' `'''|''' `''''|'''' 1)handover event | | | |2)handover request | | | | |------------------->'3)Request MN's profile | | | (multicast info.) +--------------+------->+ | | |4)Response with MN's profile | | |<----------------------| | | | (multicast info) | | | | | | | | |5)multicast | | | |------------->| 6)multicast group | | | subscription|<===================>| | |7)multicast | management | | |<-------------| | | |5)handover response | subscription respone | | |<------------------ | | | | Figure 5: Proxy mobile multicast service during fast handover 4.3. Termination of proxy mobile multicast service 4.3.1. Terminated from network When it is the time to get to the end of some on-going multicast services or no any mobile node are receiving it, or for some other reasons, the MAG can decide to terminate those multicast services no matter whether the multicast source works or not. On this occasion, the MAG will inform the LMA/multicast router about this event. 4.3.2. Terminated by mobile node The Mobile Node sends MLDv2[RFC3810] done message to the MAG and inform the MAG that it will never receive them again. Upon receipt this information the MAG will do necessary verification for ZHAO & Seite Expires January 14, 2010 [Page 13] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 authorization or authentication, then stop sending those multicast services to MN again. Accordingly, if no one receiver of a/some multicast service under the MAG, it can inform the LMA about this event. ZHAO & Seite Expires January 14, 2010 [Page 14] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 5. Mobile Access Gateway Operation For the MAG, whether the MN will run MLDv2[RFC3810] protocol or not is all right. The MAG should have the capability to interact with the MN via the MLDv2[RFC3810] messages. And there is no need to ask the MN to send the MLDv2[RFC3810] message to initiate or stop a multicast service. The MAG can get related multicast information of the MN from policy stores etc., to initiate or terminate a multicast service. Meanwhile, the MAG can disable all timers listening to MLDv2[RFC3810] query sent to the MN. As to the problem when the multicast should be ended, it depends on related network policy and MN's interest. And the termination of multicast can be triggered by both of network and MN. 5.1. Operated as the MLDv2 Proxy For route optimization reason, the MAG should have the ability to join a Multicast group without the bi-direction tunnel between the MAG and LMA. This can be based on a pre-configured configuration or MN's profile or a interaction between the MAG and LMA. To reduce the heavy load to implement the multicast router on a MAG, one MLDv2[RFC3810] listener is enough to that MAG. 5.2. Operated as the MLDv2 Router In this case,the MAG should support those feature specified for MLDv2[RFC3810] Router.The communication way between MAG and LMA is the multicast protocol. Meanwhile, the MAG can support a Multicast Router or listener are connected over the air-interface. 5.3. Operated as the MLDv2 listener If network decides that MAG doesn't deal with MLDv2[RFC3810] protocol in the interface to the mobile node, the MAG can just be operated as a MLDv2[RFC3810] listener. The MAG will collect those multicast related information about those mobile nodes under it, and base on the policies defined by network to make mobility multicast management for the mobile node. The protocol between the MAG and upper level multicast entity should be MLDv2[RFC3810] protocol. And that multicast entity can be either the LMA or a standalone multicast router. If the LMA become the multicast entity that MAG must face to communicate with, then the PMIPv6[RFC5213] protocol can also be used to achieve the goal. ZHAO & Seite Expires January 14, 2010 [Page 15] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 6. Local Mobility Anchor Operation 6.1. Operated as the MLDv2 Proxy In PMIPv6[RFC5213], every MAG and LMA will own a bi-direction tunnel. There are only these two nodes on this tunnel. Meanwhile, the PBUs/ PBAs are applicable for multicast group management. In addition, since the tunnel between the MAG and LMA can be multicast capable, MLDv2[RFC3810] can also be run in that tunnel. To one multicast group, the MAG can only join once to the LMA, it will save a large signal consumption and multicast traffics to avoid making the tunnel to be involved in the neck phenomenon. A MLDv2 proxy[RFC4605] can simplify the implementation of the LMA. At this point, it is a valuable choice as well. The benefit is similar to the description of MLDv2 proxy[RFC4605] on the MAG. To query those MAGs which are connected to a LMA, the LMA which is acting as an MLDv2 proxy[RFC3810] can use MLDv2[RFC3810] Query messages or PBAs (Need some extensions) to inform the MAGs. And then, if the LMA receives MLDv2[RFC3810] Report messages or PBUs (Also need some extensions) from MAGs, it will forward or send MLDv2[RFC3810] Report messages to the multicast router it has connected with by using it's link-local address. That belongs to current regular multicast domain. As a MLDv2 proxy[RFC3810], the LMA needs to configure its upstream and downstream interfaces statistically. As to downstream, it is connected to those MAGs and for upstream. Since, there are some many different prefixes on the LMA, it can select one or several interfaces owned by respective prefixes as the multicast listener interface faces upstream. 6.2. Operated as the MLDv2 Router If MAG like to run the multicast route protocol with LMA in the data plane, the LMA can play as a MLDv2 Router to communicate with the MAG. ZHAO & Seite Expires January 14, 2010 [Page 16] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 7. Mobile Node Consideration 7.1. Operation without the MLDv2 After all, the MLDv2[RFC3810] protocol needs hosts to support and the cost of MLDv2[RFC3810] protocol over air-interface is existed. In addition, the network has such information can be referred in pmip domain. The MAG can establish and maintain the proxy mobile multicast service to represent the MN. So the MN can just keep listening the multicast traffics without sending any explicit messages to the MAG to manage the multicast services. It should be noted that, even if the MLDv2[RFC3810] report is not expected to be sent to the MAG many kernel implementation requires host's application to create/add joined multicast group membership structure inside its kernel and open device driver to capture the data whose IP multicast address is a specified one. If no such operation, the host must receive all multicast datas with promiscuous mode, which is worst and not willing to any host. To make the system available in this kind of worst situation, unicast can be used between the MAG and mobile node to transfer those specified multicast traffics. the MAG can just play as a MLDv2[RFC3810] listener. After receiving those multicast traffics, the MAG can encapsulate them destined to the mobile node directly. As to detail port will be used, it will be provided as the part of the profile the MAG has just found. Because, currently p2p link is specified to PMIPv6[RFC5213]. So multicast or unicast between the MAG and the mobile node will not bring any additional cost to it. Note: Here the static multicast services can be used and the service is pre-configured. No any substantial large change after signing those services with operators or the deployment of them in network side. Meanwhile, some layer-2 mechanism or custom-specific protocols can be used to help the multicast group management for the mobile node when dynamic multicast service is expected to this architecture. In this case, the MAG doesn't need to run the MLDv2[RFC3810] protocol with the mobile node. ZHAO & Seite Expires January 14, 2010 [Page 17] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 8. Protocol compatible considerations By the introduction of the different roles of the MAG and the LMA, the co-ordination between the different type of the p-MAG and the n-MAG is a requirement. But, of course, we can pre-defined or advice to operators to only deploy one type of function (MLDv2 proxy[RFC3810]/MLDv2 router etc) inside of the MAG or LMA. That can make both protocol and PMIPv6[RFC5213] domain as simple as possible. Upon this assumption, a negotiation will be needed. Here we can utilize context transfer or policy store. And a dual-mode MAG will be required to be operated in different method. 8.1. Negotiation during handover TBD. ZHAO & Seite Expires January 14, 2010 [Page 18] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 9. Protocol considerations This part describes those extensions or definitions to current PMIPv6[RFC5213] protocol, or context transfer progress. 9.1. PMIPv6 messages extension Once PMIPv6[RFC5213] is used as the pmip multicast management method between the MAG and the LMA, then it will be needed to be extended to support the transfer or negotiation of those multicast related information. 9.2. Context definition during handover Although, whether the protocol will be used in PMIPv6[RFC5213] domain or not is not clearly by far. And practice system have some their specific methods to do that. But it is the same what should be transferred during context transfer progress. Once that context transfer protocol is certain, this part of work can be referred together. 9.3. Protocol configuration variables TBD. 9.4. MTU consideration If the mobile nodes under a MAG use difference MTU setting to communicate with others, the MAG need to know about this situation, and select a maximum value as the MTU value to inform HA to send the multicast traffics. 9.5. IPv4-IPv6 co-existence If NSP is IPv4 but ASP use the IPv6 or vice versa, the related IPv4- IPv6 co-existence need to be investigated. 9.6. IPv4 considerations Comparing to IPv6, the IPv4 have following difference in multicast: 1. There is broadcast exist. 2. There is the TTL need to be consider.But if MAG can just re-new the multicast request, it seems no such big problem. 3. There is some local multicast group without the need to join them explicitly. ZHAO & Seite Expires January 14, 2010 [Page 19] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 9.7. Source of Multicast request What is the source address of those multicast requests sent from MAG? the address of MAG or the ip addresses of those mobile nodes? 9.8. Handling of joining local multicast group What should to be done on MAG after receiving a joining multicast group? It should represent mobile node to join into all multicast groups or just some global ones. To those well-known multicast how should to do ? Maybe the MAG can deal with them directly. ZHAO & Seite Expires January 14, 2010 [Page 20] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 10. Security Considerations To pmip multicast service, we should base on current pmip security consideration and multicast security mechanism. To detail, it is TBD. ZHAO & Seite Expires January 14, 2010 [Page 21] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 11. Acknowledgements The author would like to acknowledge the input on specific implementations from others. ZHAO & Seite Expires January 14, 2010 [Page 22] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 12. Normative References [I-D.deng-multimob-pmip6-requirement] Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast Support Requirements for Proxy Mobile IPv6", draft-deng-multimob-pmip6-requirement-01 (work in progress), October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. ZHAO & Seite Expires January 14, 2010 [Page 23] Internet-Draft The Solution for Pmipv6 Multicast Service July 2009 Authors' Addresses YuanKui ZHAO Individual Consultant Ban Quan Road Shanghai 201206 P.R.C Phone: +86 21 13301750545 Email: yuankui.zhao@gmail.com Pierrick Seite France Telecom 4, rue du Clos Courtel BP 91226, Cesson-Sevigne 35512 France Email: pierrick.seite@orange-ftgroup.com ZHAO & Seite Expires January 14, 2010 [Page 24]