Network Working Group Y. ZHAO(Editors) Internet-Draft SH. Huawei Tech. Intended status: Standards Track October 28, 2008 Expires: May 1, 2009 The solution for pmip multicast service draft-zhao-multimob-pmip6-solution-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2009. ZHAO(Editors) Expires May 1, 2009 [Page 1] Internet-Draft The solution for pmip multicast service October 2008 Abstract An example. 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 network . . . . . . . . . . . . . . . . 6 4.1.2. Triggered by mobile node . . . . . . . . . . . . . . . 7 4.2. proxy mobile multicast service during handover . . . . . . 8 4.3. Termination of proxy mobile multicast service . . . . . . 8 4.3.1. Terminated from network . . . . . . . . . . . . . . . 8 4.3.2. Terminated by mobile node . . . . . . . . . . . . . . 8 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 9 5.1. Operated as MLD Proxy . . . . . . . . . . . . . . . . . . 9 5.2. Operated as MLD Router . . . . . . . . . . . . . . . . . . 9 5.3. Operated as MLD listener . . . . . . . . . . . . . . . . . 9 6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10 6.1. Operated as MLD Proxy . . . . . . . . . . . . . . . . . . 10 6.2. Operated as MLD Router . . . . . . . . . . . . . . . . . . 10 7. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 11 7.1. Operation without MLD . . . . . . . . . . . . . . . . . . 11 8. Protocol compitable considerations . . . . . . . . . . . . . . 12 8.1. negotiation during handover . . . . . . . . . . . . . . . 12 9. Context definition during handover . . . . . . . . . . . . . . 13 10. Protocol configuration variables . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 ZHAO(Editors) Expires May 1, 2009 [Page 2] Internet-Draft The solution for pmip multicast service October 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(Editors) Expires May 1, 2009 [Page 3] Internet-Draft The solution for pmip multicast service October 2008 2. Introduction Multicast is a very important fundamention service. It can be applied to support so many difference applications, such as IPTV,MBMS etc.Meanwhile,Proxy mobile IP is a technology to be provided to those hosts that didn't need MIP to do mobility management by network.So how to support multicast service for hosts used the proxy mobile IP protocol is needed to be designed and definitioned. draft-deng-multimob-pmip6-requirement-01.txt has discussed this kind of requirement. In this draft, we will discuss how to meet those requirement and make the hosts with pmip protocol to support multicast. ZHAO(Editors) Expires May 1, 2009 [Page 4] Internet-Draft The solution for pmip multicast service October 2008 3. Conventions & Terminology TBD. ZHAO(Editors) Expires May 1, 2009 [Page 5] Internet-Draft The solution for pmip multicast service October 2008 4. Overview To proxy mobile multicast protocol, we need to re-use those current existed mature protocols related to pmip and multicast as more as possible. And keep the requirement of mobile node as simple as possible. In this direction, it need to keep consistent with RFC5213. The MAG can represent the MN to establish and maintenance the multicast service based on existed info provided by pre-config , policy store, context transfer or even MN's request.And the multicast service can be terminated by MN,network policy or multicast service it self. 4.1. Initiation of proxy mobile multicast service The mobile multicast service in proxy mobile IP domain can be initiated by both of network and mobile node. They have the common handover process. When it is initiated from mobile node, the MN will need to send IGMP/MLD to triggered MAG to start to establish the multicast service,Meanwhile, from those profile infomation or some pre-configured materials , MAG can just start the multicast service represent that Mobile node without the need of IGMP/MLD sent from Mobile node. Becarefully, even in this case, Mobile node still can ask for join some multicast group, it is no any impact on that. 4.1.1. Triggered from network In some multicast architecture, the MAG may initiate multicast subscription.In that case,the MAG will initiates multicast subscription and MN just sends IGMP to avoid the packet to be filtered by the OS; but IGMP is not sent to the network. And if implementation support,MN can also didn't send MLD out to ask for join those related multicast group. When the MN just attachs to a MAG, the MAG gets the MN's profile and knows some pre-configured multicast services need to be established, then it will request the LMA to provide the respective service, in this case, the method used to communicate to LMA from MAG can be either PMIP signals or MLD report(join) messages etc. LMA will check about this request and do the decision based on it's acknowledges about it. The progress as the following: ZHAO(Editors) Expires May 1, 2009 [Page 6] Internet-Draft The solution for pmip multicast service October 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)PMIP Registration | | | | | &Multicast joining | | | | |---------------------->|________|__________ | | | |6)possible multicast | | | | |authorization progress| | | | '`'''''''''''''''''''''' | | | | | | | | | 7)Multicast joining | | | |--------+----------->| |8)Multicast| 8)Multicast traffic | 8)Multicast traffic | |<----------|<----------------------|<--------------------| | | | | | Figure 1: Network-Initiated multicast service establish progress 4.1.2. Triggered by mobile node If the mobile node knows some multicast groups should be joined , it can send MLD report to MAG about those target multicast groups it want to join in. In addition, if the mobile node has just received the MLD query from MAG, it can also response to it by MLD report including those multicast groups it want to receive. After receiving MLD report sent from MN,MAG will inform this to LMA/ Multicast router. But before that, MAG will do some related authorization or authentication to check about this request. Meanwhile,MAG didn't need to inform LMA/Multicast router about every request from MNs, it just inform LMA about those the firstest comer ZHAO(Editors) Expires May 1, 2009 [Page 7] Internet-Draft The solution for pmip multicast service October 2008 to some one multicast group. 4.2. proxy mobile multicast service during handover Generally,without any optimization,the handover will need the involved of MNs by sending MLD report to inform new MAG about those multicast services they want to receive. But,for performance consideration,the CXT is expect to provide necessary multicast infomation during handover progress. And if needed, a 3-rd party policy store is required to be used to provide necessary information whenever CXT will be used or not. 4.3. Termination of proxy mobile multicast service 4.3.1. Terminated from network When the schedule of some on-going multicast service is to the end,then the MAG can terminate to send those traffic to MNs whatever the multicast source is work or not.If no receiver of a multicast service under a MAG is existed, it will inform LMA about this event by related signals depend on which one is selected by LMA, for example, PBU/PBA,MLD leave message etc. 4.3.2. Terminated by mobile node Mobile Node will send MLD leave message to inform MAG about the termination of a/some multicast service if he won't receive that service.After receiving that and finishing some necessary checkings for authorization or authentication , MAG will end to send that/those multicast services to MN again. Respectly, if no one receiver of a/some multicast service under the MAG will be existed,MAG can inform LMA about this event by related signals depend on which one is selected by LMA, for example, PBU/PBA,MLD leave message etc. ZHAO(Editors) Expires May 1, 2009 [Page 8] Internet-Draft The solution for pmip multicast service October 2008 5. Mobile Access Gateway Operation To MAG, whether MN will run MLD protocol is not the key. MAG should have the ability to interact with MN via MLD messages.And it also didn't need to ask MN must to send the MLD message for initiate or end a multicast service.Respectively, MAG can get related multicast infomation for particular MN from such as policy store, to initiate or terminate a multicast service. Meanwhile,MAG can disable all timers listening for MLD query if it has sent to MN.As to when the multicast should be ended, that will depend on related network policy and MN's interesting,and can be triggered from both of network and MN. 5.1. Operated as MLD Proxy TBD. 5.2. Operated as MLD Router TBD. 5.3. Operated as MLD listener For route optimization reason, MAG should have the ability to join a Multicast group without the bi-direction tunnel between MAG and LMA.This can based a pre-configured configuration or MN's profile or a interaction between MAG and LMA. But difference the possible multicast router in current design, the MAG no need so heavy implement to support it. A MLD listener is enough. ZHAO(Editors) Expires May 1, 2009 [Page 9] Internet-Draft The solution for pmip multicast service October 2008 6. Local Mobility Anchor Operation 6.1. Operated as MLD Proxy In pmipv6,every MAG and LMA will own a bi-direction tunnel. There are only these two nodes on this tunnel. Meanwhile, there are PBUs/ PBAs are applicable for multicast group management. In addition, since the tunnel between MAG and LMA can be multicast capable,IGMP/ MLD can also be run in that tunnel.To one multicast group, MAG can only join once to LMA,it will save a lagre signal consumtion and including following multicast traffics invoide to make the tunnel to be involved the neck phenomenon. A MLD proxy can simplify the implementation of LMA, so that is a valued choice as well.The benefit is similiar to the description of MLD proxy located on MAG. To query those MAGs connected to a LMA,the LMA acting as an MLD proxy can use MLD Query messages or PBAs(Need some extensions) to inform those MAGs.After that, if LMA receives MLD Report messages or PBUs(Also need some extensions) from MAGs,it will forwards or send MLD Report messages to the multicast router it has connected with using it's link-local address. That is belong to current regular multicast domain. As a MLD proxy, LMA need configure its upstream and downstream interfaces statistically.To downstream , it is connected those MAGs and to upstream , it is suggested a multicast router or maybe the multicast source is dedicated. Since, there are some many difference prefixes located LMA,it can select only one or several interfaces owned for respective prefixes as the multicast listener interface face to upstream. 6.2. Operated as MLD Router TBD. ZHAO(Editors) Expires May 1, 2009 [Page 10] Internet-Draft The solution for pmip multicast service October 2008 7. Mobile Node Consideration 7.1. Operation without MLD After all, the MLD protocol need host to support and the transfermation of MLD protocol over air-interface will cost another consumetion. In addition, the network have so many infomation can be referenced in some cases in pmip domian. MAG can establish and maintenance the proxy mobile multicast service represent the MN. So MN can just keep listening about the multicast traffic without send any expicite messages to MAG to manage the multicast service. It should be noted that, even if MLD 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 the specified one. If no such operation, the host must receive all multicast data with promiscuous mode, which is worst and not willing to any host. To this case, one hand,this mode is applicable to those hosts that didn't support MLD protocol.In addition, to those support MLD hosts it will rely on the management of MAG. Since the link mode is p2p link. the MN is only connected to MAG on like. So it require the MAG just control to send which kind of multicast services and send what to this mobile node. In another hand, to p2p link, what will be the promiscuous mode? Since all of data need to be received by hosts, and MAG just kick off those service that not related to that MN.So,it will be not worst in pmip case. ZHAO(Editors) Expires May 1, 2009 [Page 11] Internet-Draft The solution for pmip multicast service October 2008 8. Protocol compitable considerations By the introduction of difference roles of MAG and LMA, the co- ordination between the differentiate type of p-MAG and n-MAG is a requirement. But, of course, we can pre-defined or advice to operators to only deploy one type of function (MLD Proxy/MLD Router etc) inside of MAG or LMA. That can make both of this protocol and PMIPv6 domain as simple as possible. If we can make this assumtion, then a negotiation will be needed. Here we can utilize CXT or policy store to do this. And a dual-mode MAG will be required to be operated in different method. 8.1. negotiation during handover TBD. ZHAO(Editors) Expires May 1, 2009 [Page 12] Internet-Draft The solution for pmip multicast service October 2008 9. Context definition during handover ZHAO(Editors) Expires May 1, 2009 [Page 13] Internet-Draft The solution for pmip multicast service October 2008 10. Protocol configuration variables ZHAO(Editors) Expires May 1, 2009 [Page 14] Internet-Draft The solution for pmip multicast service October 2008 11. Security Considerations To pmip multicast service, we should based on current pmip security consideration and multicast security mechanism. To detail,it is TBD. ZHAO(Editors) Expires May 1, 2009 [Page 15] Internet-Draft The solution for pmip multicast service October 2008 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ZHAO(Editors) Expires May 1, 2009 [Page 16] Internet-Draft The solution for pmip multicast service October 2008 Author's Address Yuan Kui.ZHAO Shanghai Huawei Technology Qian Chang Building No.450,Jin Yu Road, Shanghai, Shanghai 201206 P.R.C Phone: +86 21 28920578 Email: john.zhao@huawei.com URI: http://www.huawei.com/ ZHAO(Editors) Expires May 1, 2009 [Page 17] Internet-Draft The solution for pmip multicast service October 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(Editors) Expires May 1, 2009 [Page 18]