Internet DRAFT - draft-shin-magma-mzmp
draft-shin-magma-mzmp
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| |
| +----+ |
+------------------------------------------------------+
<Figure 1> 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| |
| | | |
| +----+ |
+------------------------------------------------------+
<Figure 2> 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) | | |
|<---------------------| | |
| | | |
| | | |
| | | |
| | | |
<Diagram 2> 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)
<Figure 3> 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) | |
| | | |
| | | |
| | | |
<Diagram 3> 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| |
| | | |
| +----+ |
+------------------------------------------------------+
<Figure 4> 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) | | |
|<---------------------| | |
| | | |
| | | |
<Diagram 4> 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]
