Magma Working Group Yongtae Shin Internet-Draft Sangjin Park Expires: May 10, 2006 Yuhwa Seo ICN LAB of Soongsil UNIV Jongwon Choe Sookmyung UNIV October 2005 MBS zone Management Protocol(MzMP) for the Multicast draft-shin-magma-mzmp-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 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document presents consideration item and guide line of multicast service environment construction as technology research for efficient multicast service support in common use carrying along internet topology is changed through the result in 2.3GHz carrying along internet topology that become major of mobile internet. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 1] Internet-Draft MzMP for the Multicast October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 02 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 03 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 03 3.1 MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 03 3.2 MBS Server . . . . . . . . . . . . . . . . . . . . . . . . . 03 3.3 BS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 03 3.4 ASA Server . . . . . . . . . . . . . . . . . . . . . . . . . 03 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 04 4.1 Extension of MBS zone . . . . . . . . . . . . . . . . . . . . 04 4.1.1 BS1 subscribes the MBS zone . . . . . . . . . . . . . . . . 04 4.1.2 MSS entered BS1 region subscribing at MBS zone . . . . . . 05 4.1.3 MSS1 moved another BS region . . . . . . . . . . . . . . . 08 4.2 Reduction of MBS zone . . . . . . . . . . . . . . . . . . . 09 4.2.1 Last recipient discontinued multicast service group in BS1 that is subscribed to MBS zone . . . . 09 4.2.2 Last recipient moved out BS1 region subscribed to MBS zone. 10 5. Multicast data transmission of MBS Server . . . . . . . . . . 11 6. MBS zone list management of BS . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Various derivative technologies of present mobile internet are developed as commercialized technology. Among it, multicast and fusion of Mobile technology may cause elevation of technique many services. Do so that can provide various service defining important technology of such problem in this document. Take advantage of WLAN technology in mobile spot area in downtown, because other area with transfer tele topology, dynamic group management and service management for node who can use multicast without that have mobility in carrying along internet environment are possible. Also, pare down waste of mobile bandwidth utilizing group management who is simplified than ex group management techniques in carrying along internet environment and group management of base station(BS) decreasing process of transfer node, because do transfer node power consumption decrease possible. Finally, wide multicast services support capacitates because connecting with technology of Mobile VoIP, MANET, Telemetics, PAN, MBWA etc. So this document suggested to novel MBS zone Management Protocol(MzMP) based on the MBS zone concept for supporting effective multicast service and group management over IEEE 802.16e. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 2] Internet-Draft MzMP for the Multicast October 2005 2. Terminology MBS: Multicast & Broadcast Service MCID (Multicast CID): The identifier that classified the multicast service and MBS zone MBS Zone: The region provide multicast and broadcast service that has a specific MCID MBS Zone subscribes: Receiver of the multicast service that has its MCID MBS Zone leave: Discontinue receiving multicast service that has specific MCID MBS Server: The management server of MCID and BS for multicast service BS (Base Station): The equipment supporting wireless access of MSS MSS: Mobile Subscriber Station ASA(Authentication and Service Authorization): The service and user authentication to MSS ASA Server: The server that performs grant, management and authentication of unique authentication key to each MSS DSA-RSP: The serving BS sends this message to MSS in order to response to a received DSA-REQ(connection info parameter, connection setting parameter) SA: Security Association MCID: Multicast Connection Identifier 3. Requirements 3-1 MSS - MSS should be able to receive or request MCID list from MBS Server or BS. - MSS should be able to transmit message for multicast server discontinue. 3-2 MBS Server - It should maintain the list information of BS that receives the Multicast Service Flow ID.(MCID) - It should transmit new MCID message by request of MCID list from BSs or addition new MCID to own MBS management table. - It assigns a MCID per multicast service. - It may save multicast service contents. : The contents may be stored to Media server near by MBS Server in this case, it needs message exchange with MBS Server. 3-3 BS - It should maintain MCID list from MBS Server and MSS receiving each MCID service in the region. - It should save MCID list from MBS Server during a fixed term. - It should periodically update MCID list by new MCID message from MBS Server. 3-4 SAS server - SAS server must authenticate user and service uses to MSS in correspond MBS zone region. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 3] Internet-Draft MzMP for the Multicast October 2005 4. Protocol Details 4-1 Extension of MBS zone 4-1-1 BS1 subscribes the MBS Zone +--------------+ +------------+ +------------------------------+ | ASA server | | MBS Server |----| 5.MBS management cache table | +--------------+ +------------+ | MCID#1 | BS1 | | ¡è | | +------------------------------+ | | | | 3.SA | |2.SA | |4.MBS_MAP response| |reqest | | (MCID#1 MBS Zone extend) | | | | +------------+--+--------+--+--------------------------+ | | | | | | | | | 6.ACK| | | | ¡é | ¡é | | | +-------------+ | | | | +-------------------+ | | | BS 1 |---| 7.MBS cache table | | | | | | MCID#1 | MSS1 | | | +-------------+ +-------------------+ | | | ¡è | | +----+ | | | | | | | | | | |MSS2| | | | | +----+ | | | | 8.DSA_RSP| | | | | |1.DSA_REQ | | ¡é |(MCID#1,SA request) | | +----+ | | | | | | |MSS1| | | +----+ | +------------------------------------------------------+
BS1 subscribes the MBS zone Although BS1 has not subscribed to MBS zone, it contains MCID list through periodic Advertisement message from MBS Server. MSS1 wants to provide multicast service with MCID#1 of the MCID list. MSS1 obtains MCID list from BS1. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 4] Internet-Draft MzMP for the Multicast October 2005 Figure 1 shows below sequence. 1. MSS1 send the DSA_REQ message (MCID, SA information, etc) to BS1 for request and authentication of MCID#1. 2. BS1 send the authentication request message to ASA server for the MSS1. 3. ASA server sends SA response message of MSS1 to BS1. 4. If authentication of MSS1 is completed, the BS1 sends the MBS MAP message to MBS Server for requests to subscribe MBS zone. 5. MBS Server registers BS1 as a multicast subscriber of MCID#1, and maintains the table. 6. MBS Server send ACK message to BS1. 7. BS1, received ACK message, registers and manages MCID#1 and MSS1 in a table that contains information of its multicast service. 8. MSS1 receive the DSA_RSP message from BS1. DSA_RSP means that multicast service data zone broadcasting in BS1 by engaged SA. MSS1 BS1 ASA server MBS server | | | | | 1.DSA REQ | | | |(MCID#1, SA request) | | | |--------------------->| | | | | | | | | 2.SA request | | | |------------------>| | | | | | | | 3.SA response | | | |<------------------| | | | | | | | | | | | 4. MBS_MAP | | | | (MCID #1, MBS Zone extend) | | |-------------------|---------------->| | | | 5.MBS | | | management | | ACK | cache table | |<------------------|-----------------| | | | | | |7.MBS cache table | | | | MCID#1 | | | | | | | | | | | 5.DSA_RSP | | | | (SA response) | | | |<---------------------| | | | | | | | | | | < Diagram 1 > BS1 subscribes the MBS zone Shin&Park&Seo&Choe Expires May 10, 2006 [Page 5] Internet-Draft MzMP for the Multicast October 2005 4-1-2 MSS entered BS1 region subscribing at MBS zone +--------------+ +------------+ | ASA server | | MBS Server | +--------------+ +------------+ 4.SA | ¡è 3.SA Response| | request | | | | +-------------+-+--------------------------------------+ | | | | | ¡é | | | +-------------+ | | | | +-------------------+ | | | BS1 |---| 2.MBS cache table | | | | | | MCID#1 | | | +-------------+ +-------------------+ | | |¡è | | | | | | 5.SA | | 1.DSA_REQ | | response¡é | (MCID#1, SA request) | | +----+ | | | | | | |MSS2| | | +----+ | | +----+ | | |MSS1| | | | | | | +----+ | +------------------------------------------------------+
MSS entered BS1 region subscribing at MBS zone BS1 already has subscribed MBS zone, and when MSS2 enters its region, MSS2 receives MCID list from BS1 and wants to provide multicast service of MCID#1. MBS cache table of BS1 already has contained recipient MSS1 of MCID#1. Figure 2 shows below sequence. 1. MSS2 sends the DSA_REQ message to BS1 for request and authentication of MCID#1 multicast service. 2. BS1 checks whether existence of MCID#1 in own MBS cache table. 3. BS1 sends SA request message to ASA server for MSS2 authentication. 4. ASA server send authentication SA response message for MSS2. 5. MSS2 receives DSA_RSP message from BS1. In this case DSA_RSP means that broadcasting multicast service data in BS1 zone depending on the SA. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 6] Internet-Draft MzMP for the Multicast October 2005 MSS1 BS1 ASA server MBS server | | | | | 1.DSA REQ | | | |(MCID#1, SA request) | | | |--------------------->| | | | | 2.MBS cache table | | | | | | | | | | | | 3.SA request | | | |------------------>| | | | | | | | 4.SA response | | | |<------------------| | | | | | | | | | | 5.DSA_RSP | | | | (SA response) | | | |<---------------------| | | | | | | | | | | | | | | | | | | MSS entered BS1 region subscribing at MBS zone Shin&Park&Seo&Choe Expires May 10, 2006 [Page 7] Internet-Draft MzMP for the Multicast October 2005 4-1-3 MSS1 moved another BS region A. Moved another BS region that not subscribed MBS zone +--------------+ +------------+ +-------------------+ | ASA server | | MBS Server |---| 5.MBS management | +--------------+ +------------+ | cache table | |¡è |¡è | MCID#1|BS1, BS2 | || || +-------------------+ || || || || || || +-------------------------------------++--++-------------------------+ | 3.||2.|| | | || || | | || || | | +-----------------+ ||6.||4. | | | MBS cache table | || || | | +| MCID#1 |-----------+ || || | | |+-----------------+ | || || | | | | +---------+---++--++--------------+ | | | | +----+ | | ¡é| ¡é| | | | | +---|BS1 | | 7. | +----+ | | | | | | | +------+---|BS2 | +----------+--------+ | | | +----+ | | +----+-->| |---| 6.MBS cache table | | | | | | |1. | +----+ | MCID#1|MSS2 | | | | | | | | |¡è +----------+--------+ | | | +----+ | ¡é | | 7.|| 1. | | | | +----+ |MSS2|===>+----+ | || | | | | |MSS1| +----+ | |MSS2|=====>+----+ | | | | +----+ | +----+ | |MSS2| +----+ | | | | | | +----+ |MSS3| | | | | | | +----+ | | | +--------------------+---------+ | | | | | | | +---------------------------------+ | +--------------------------------------------------------------------+ 1. DSA_REQ (MCID#1 request) 2. SA request 3. SA response 4. MBS_MAP (MCID#1 MBS zone extend) 5. MBS management cache table MCID#1 | BS1,BS2 6. ACK 7. MBS cache table MCID#1 | MSS2 8. DSA_RSP (SA response)
MSS1 moved another BS region When MSS2, it provided service of MCID#1 in BS1, moves into BS2 that has not subscribed MBS zone of MCID#1, the same procedure is performed step 1 to 7 of section 3.1 Request message of MCID#1 in Step 1 can be requested in crossing region between BS1 and BS2, or after complete entering the BS2. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 8] Internet-Draft MzMP for the Multicast October 2005 B. Moved another BS region that subscribed MBS zone. If MCID#1 MBS zone recipient already has been existed in BS2, each table of BS2 and MBS Server already hascontained MCID#1, and a table of MBS Server also registered BS2 as service recipient to MCID#1. So the procedure at section 3-2 is performed. MSS2 BS2 ASA Server MBS Server | | | | |==========>| | | |1.DSA_REQ | | | |(MCID#1 request) | | | | | | | | | | | |----------->| | | | 2.SA | | | | request | | | | | | | |<-----------| | | | 3.SA | | | | response | | | | | | | |---------------------->| | | 4.MBS_MAP | | | |(MCID#1 MBS zone extend) | | | | | | | 5.MBS management | | | cache table | | | MCID#1| BS1,BS2 | | 6.ACK | | | |<----------------------| | | | | | 7. MBS cache table | | | MCID#1 | MSS2 | | | | | | |<----------| | | | 8.DSA_RSP | | | |(SA response) | | | | | | | | | | | | | | MSS1 moved another BS region Shin&Park&Seo&Choe Expires May 10, 2006 [Page 9] Internet-Draft MzMP for the Multicast October 2005 4.2 Reduction of MBS zone 4-2-1 Last recipient discontinued multicast service group in BS1 that is subscribed to MBS zone +--------------+ +------------+ +------------------------------+ | ASA server | | MBS Server |---| 4.MBS management cache table | +--------------+ +------------+ | MCID#1 | BS1 delete | 7.SA expire| ¡è6.SA | ¡è3.MBS_MAP +------------------------------+ ACK | |request | |(MCID#1, MBS zone reduce) | | | | +------------+--+--------+--+--------------------------+ | | | 5.ACK| | | | ¡é | ¡é | | | +-------------+ | | | | +-------------------+ | | | BS1 |---| 2.MBS cache table | | | | | | MCID#1 delete | | | +-------------+ +-------------------+ | | | ¡è | | | | | | 8.DSA_RSP | |1.DSA_REQ | | (SA expire,ACK)| |(MCID#1, SA request) | | | | | | ¡é | | | +----+ | | |MSS1| | | | | | | +----+ | +------------------------------------------------------+
Reduction of MBS zone BS1 has subscribed to MBS zone, so it has maintained and managed MBS cache table that recorded informationto MSS, which it received MCID list and each MCID. When last MSS1 of MCID#1 discontinues the service due to several reason, or when SA is expired. Also, the reduction of MBS zone is performed, when BS1 leaves its MBS zone and MBS zone is reduced. Figure 4 shows below sequence. 1. MSS1 sends DSA_REQ message to BS1 for MCID#1 service discontinuance and for SA cancellation. 2. BS1 deletes the related information of MSS1 in MBS cache table. 3. BS1 sends the MBS_MAP message for MBS zone reduce message of MCID#1 to MBS Server, because no more necessity providing multicast service of MCID#1. 4. MBS Server deletes BS1 of MCID#1 entry in MBS zone management table. 5. MBS Server sends ACK message to BS1. 6. BS1 sends SA release message of MSS1 to ASA server. 7. ASA server sends SA1 expire ACK message to BS1. 8. BS1 send the DSA_RSP message for SA expire ACK message to MSS1 and MSS1 expire own SA. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 10] Internet-Draft MzMP for the Multicast October 2005 MSS1 BS1 ASA server MBS server | | | | | 1.DSA REQ | | | |(MCID#1, SA request) | | | |--------------------->| | | | | | | | |2.MBS cache table | | | | | | | | | | | | 3.MBS_MAP | | | | (MCID #1, MBS Zone extend) | | |-------------------|---------------->| | | | 4.MBS | | | management | | ACK | cache table | |<------------------|-----------------| | | | | | | 6.SA release | | | |------------------>| | | | | | | | 7.SA expire ACK | | | 5.DSA_RSP |<------------------| | | (SA expire ACK) | | | |<---------------------| | | | | | | | | | | Reduction of MBS zone 4-2-2 Last recipient moved out BS1 region subscribed to MBS zone When the last recipient MSS1 of BS1 moved another BS region, BS1 dose not detects data exchange for MCID#1 any more. In this case, after during for fixed term, MBS zone reduced by performing step 3 to 7 in section 4-1. 5. Multicast data transmission of MBS Server MBS Server may become Media server to provide contents, or Multicast server separate from Media server. In case of the separated system, MBS Server distributes data to each BS for communicating with Media server. MBS Server has the information of BSs with their MCID in MBS zone, and transports their own data to corresponding BSs. In MSS is source of multicast data, MSS sends own data to its BS, and BS sends the data to MBS Server. After, multicast data transmission is similar to central server. 6. MBS zone list management of BS MBS obtains current using MBS zone list from MBS Server by periodically, or Advertisement message of MBSServer. As BS saves MBS zone list, if MSS requested MBS zone list to MBS Server, we will be able to reduce correspond delay and bandwidth waste. MBS Server sends the MBS list to as BS by request of the BS, and it sends new MCID message to the BS, whenever adding new MCID in own MBS management table. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 11] Internet-Draft MzMP for the Multicast October 2005 7. Security Considerations More improvement way that is proposed in after through performance estimation, and security part that is limitation of mobile environment and DRM part that can protect intellectual property of multimedia contents research about works that need. 8. References [1] Internet Protocol, version 6(IPv6) specification, RFC 2460, 1998. 12 [2] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for 6 (IPv6)", RFC 2461, 1998. 12. [3] Charles E. Perkins and David B. Johnson, "Mobility Support in IPv6", Internet Draft, draft-ietf-mobileip-ipv6-24, 2003. 12. [4] Pat R. Calhoun and Tony Johansson, "Diameter Mobile IPv4 Application", Internet Draft, draft-itef-aaa-diameter-mobileip-11 2002. 6. [5] R. Koodli et al, "Fast Handovers for Mobile IPv6", Internet Draft draft-ietf-mobileip-fast-mipv6-06, 2003. 3 [6] S. Deering, "Host Extensions for IP Multicasting", Internet RFC112, 1989. 8. [7] "Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access System", Draft IEEE Standard for Local and metropolitan area networks-IEEE 802.16e/D5, 2004. 9. [8] Charles E. Perkins, Addison-Wesley, "Mobile IP: Design Principles and Practices" [9] Charles E. Perkins and David B. Johnson, "Mobility Support in IPv6" Shin&Park&Seo&Choe Expires May 10, 2006 [Page 12] Internet-Draft MzMP for the Multicast October 2005 Authors' Information Yongtae Shin Room 422 Information Science B/D, Soongsil University Sangdo5-dong Dongjak-gu Seoul, 156-743, South Korea Email: shin@cherry.ssu.ac.kr Sangjin Park Room 402 Information Science B/D, Soongsil University Sangdo5-dong Dongjak-gu Seoul, 156-743, South Korea Email: parking@cherry.ssu.ac.kr Yuhwa Seo Room 402 Information Science B/D, Soongsil University Sangdo5-dong Dongjak-gu Seoul, 156-743, South Korea Email: zzarara@cherry.ssu.ac.kr Jongwon Choe Room 410A Information Science B/D, Sookmyung University Hyochangwon St.52 Yongsan-gu Seoul, 140-742, South Korea Email: choejn@sookmyung.ac.kr Shin&Park&Seo&Choe Expires May 10, 2006 [Page 13] Internet-Draft MzMP for the Multicast October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shin&Park&Seo&Choe Expires May 10, 2006 [Page 14]