1. Multicast Scope Date:2006-09-17 Authors: September 2006 Month Year
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Amy Zhang et al
Amy Zhang et al

2. Month Year
September 2006
September 2006
Abstract
This document suggests multicast requirement for Wireless LAN, specifically providing motivation of the requirement, reviewing some current practices, and suggesting requirements based on use case.
Amy Zhang et al
Amy Zhang et al

3. Agenda Why multicast Current practices Suggestions September 2006
Month Year
September 2006
September 2006
Agenda
Why multicast
Current practices
Suggestions
Amy Zhang et al
Amy Zhang et al

4. September 2006
Why multicast
There are many multicast services provided by a SSPN, and the multicast traffics shall be isolated over the air. A multicast frame no longer needs to be sent to all the STAs associated with a BSS.
SSPN
WLAN AP
Amy Zhang et al

5. Why multicast (Cont’d)
September 2006
Why multicast (Cont’d)
Interworking with 3G
The video multicast service is supported by the video provider of 3G, and the clients are enjoying the service through the WLAN access.
The multicast traffic only needs to be transferred by AP to STAs who have subscribed such service with the video provider .
Video Provider
WAG
WLAN
3G Network AP AS
Amy Zhang et al

6. Agenda Why multicast Current practices Suggestions September 2006
Amy Zhang et al

7. Broadcast-based transferring
September 2006
Broadcast-based transferring
When AP receives a multicast frame, it broadcasts within the BSS because it does not know which STAs belong to such group.
Add the payload of STAs which are not intent to receive the frame.
Introduce security threat because all the associated STAs can receive it, which will make it visible to sniffers.
Amy Zhang et al

8. Unicast-based transferring
September 2006
Unicast-based transferring
When AP receives a multicast frame, it transmits it to all the STAs within the BSS by unicast.
When there are many STAs, it will introduce more air payload.
Add the payload of the STAs which are not intent to receive the frame.
Exist potential security threat because all the associated STAs can receive it.
Amy Zhang et al

9. Multicast-based transferring
September 2006
Multicast-based transferring
When AP receives a multicast frame, it delivers it to the group members by the multicast MAC address as DA, not to all members of the BSS.
STAs decide whether discard the multicast frame by the DA, but use the same broadcast group key to encrypt the multicast frame over the air.
The forged multicast frame ( the same multicast address as DA) from the broadcast domain can only be discarded after the decryption above layer 2.
Use the same GTK or didn’t encrypt over the air
Amy Zhang et al

10. Agenda Why multicast Current practices Suggestions September 2006
Amy Zhang et al

11. Multicast-based transferring
September 2006
Multicast-based transferring
AP shall deliver the multicast frame only to the group members, not to all members of the BSS.
Separate the multicast traffics into different groups which are mapping to different multicast services from SSPN.
Reduce other STAs’ payload
Avoid security threat
Use layer-2 multicast key MGK1
Use layer-2 multicast key MGK2
Amy Zhang et al

12. September 2006
How to multicast?
AP maintains the multicast groups which are mapping to the multicast services provided by SSPN.
Isolate the multicast traffic over the air.
According to the group address in DA, STAs decide whether discard the multicast frame or not.
Reduce STA’s payload.
Different groups may maintain different group keys for encryption/decryption. It is an choice for the WLAN provider based on the configuration.
Avoid L2 security
The group key is relative to multicast group and secretly sent to the STA which subscribed a multicast service with a SSPN.
The forged multicast frame didn’t belong to a multicast group can be quickly found based on the layer-2 group key.
Amy Zhang et al

13. Suggested Requirements
September 2006
Suggested Requirements
Because the multicast traffics are from the external network, so we suggest TGu to discuss the multicast requirement:
The traffic of different multicast services needs to be segregated over the air so that a multicast frame no longer needs to be sent to all associated STAs.
Amy Zhang et al

14. Straw poll How many like the idea of multicast scope and would like
September 2006
Straw poll
How many like the idea of multicast scope and would like
to include it in the IEEE u requirement document.
Think it is a good idea:
Bad idea:
Amy Zhang et al

15. September 2006
Motion
Move that a new requirement be added to the User Plane cluster as stated in document 05/822r11 with status “Required”. The document will then be updated to r12.
Information : The requirement text states:
R12U4：The traffic of different multicast services needs to be segregated over the air so that a multicast frame no longer needs to be sent to all associated STAs.
Moved by:
Seconded:
Result: (for-against-abstain)
Amy Zhang et al

16. September 2006
Feedback?
Amy Zhang et al