Network Working Group Y K. ZHAO Internet-Draft SH. Huawei Tech. Intended status: Standards Track P. Seite Expires: May 7, 2009 France Telecom November 3, 2008 The Solution for Pmipv6 Multicast Service draft-zhao-multimob-pmip6-solution-02.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 7, 2009. ZHAO & Seite Expires May 7, 2009 [Page 1] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 consideration about how to provide the proxy mobile multicast system. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Initiation of proxy mobile multicast service . . . . . . . 6 4.1.1. Triggered from the network . . . . . . . . . . . . . . 6 4.1.2. Triggered by the mobile node . . . . . . . . . . . . . 9 4.2. Proxy mobile multicast service during handover . . . . . . 11 4.2.1. Proxy mobile multicast service during normal handover . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Proxy mobile multicast service during fast handover . 12 4.3. Termination of proxy mobile multicast service . . . . . . 12 4.3.1. Terminated from network . . . . . . . . . . . . . . . 12 4.3.2. Terminated by mobile node . . . . . . . . . . . . . . 12 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 14 5.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 14 5.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 14 5.3. Operated as the MLDv2 listener . . . . . . . . . . . . . . 14 6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 15 6.1. Operated as the MLDv2 Proxy . . . . . . . . . . . . . . . 15 6.2. Operated as the MLDv2 Router . . . . . . . . . . . . . . . 15 7. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 16 7.1. Operation without the MLDv2 . . . . . . . . . . . . . . . 16 8. Protocol compatible considerations . . . . . . . . . . . . . . 17 8.1. Negotiation during handover . . . . . . . . . . . . . . . 17 9. Protocol consideration . . . . . . . . . . . . . . . . . . . . 18 9.1. PMIPv6 messages extension . . . . . . . . . . . . . . . . 18 9.2. Context definition during handover . . . . . . . . . . . . 18 9.3. Protocol configuration variables . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 ZHAO & Seite Expires May 7, 2009 [Page 2] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 3] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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. Such as these requirements are described in [I-D.deng-multimob-pmip6-requirement]. And in this draft, we will continue to introduce how to meet those requirements and make PMIPv6 supply multicast. ZHAO & Seite Expires May 7, 2009 [Page 4] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 5] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 6] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 _________ ____________ ........ ....... ...... | 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 May 7, 2009 [Page 7] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 RFC5312 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 May 7, 2009 [Page 8] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 _________ ____________ ........ ....... ...... | 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 May 7, 2009 [Page 9] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 _________ ____________ ........ ....... ...... | 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 May 7, 2009 [Page 10] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 11] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 12] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 13] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 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 an interaction between the MAG and LMA. To reduce the heavy load to implement the multicast router on a MAG, one MLDv2 listener is enough to that MAG. 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 May 7, 2009 [Page 14] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 TBD. ZHAO & Seite Expires May 7, 2009 [Page 15] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 16] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 17] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 9. Protocol consideration 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. ZHAO & Seite Expires May 7, 2009 [Page 18] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 19] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 11. Acknowledgements The author would like to acknowledge the assistance of Pierrick Seite, Hitoshi Asaeda and Jinwei Xia in writing this draft, and also the input on specific implementations from others. ZHAO & Seite Expires May 7, 2009 [Page 20] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 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 May 7, 2009 [Page 21] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 Authors' Addresses Yuan Kui.ZHAO Shanghai Huawei Technology Qian Chang Building No.450,Jin Yu Road, Shanghai 201206 P.R.C Phone: +86 21 28920578 Email: john.zhao@huawei.com URI: http://www.huawei.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 May 7, 2009 [Page 22] Internet-Draft The Solution for Pmipv6 Multicast Service November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. ZHAO & Seite Expires May 7, 2009 [Page 23]