doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Draft 2 group addressing text synopsis] Date Submitted: [17 March, 2005] Source: [Robert Cragie] Company [Jennic Ltd.] Address [Furnival Street, Sheffield, S1 4QT, UK] Voice:[ ], FAX: [ ], Re: [Response to the call for proposal of IEEE b] Abstract:[Discussion for several potential enhancements for current IEEE MAC] Purpose:[For the discussion at IEEE b Study Group] Notice:This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 2 Draft 2 group addressing text synopsis Robert Cragie Jennic Limited

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 3 Introduction A synopsis of the text which will be in draft 2 outlining the content of the sections with regard to group addressing Based on discussions between members of a subgroup consisting of: –Phil Beecher, CompXs –Robert Cragie, Jennic –Øyvind Janbu, Chipcon –Joseph Soma Reddy, Figure 8 Wireless –Zachary Smith, Ember –Rene Struik, Certicom

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 4 Background Document Draft 1; all section, figure and table references refer to Draft 1 Document is a proposal for a change in auxiliary security header which would accommodate the proposals in this document Acceptance of this document as the basis for group addressing text does not imply that document will also be accepted Additional points follow

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 5 Group addressing only for data frames Beacon is implicitly broadcast and contains no destination address, so is not eligible for group addressing Acknowledge contains no destination address, so is not eligible for group addressing Currently only two command frames which use broadcast: –Beacon request –Coordinator realignment Both command frames need to be implicitly broadcast because of their nature If they need to be secured, explicit key identifier can be used The mechanism proposed must however not be restricted to data frames as it is conceivable that all frame types in future revisions may be eligible for group addressing

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 6 Addressing modes Use of group addressing bit redefines the meaning of the destination address Current proposal is to use destination address modes 2 and 3 for group addressing, i.e. this would allow 16-bit and 64-bit group identifiers Current proposal is to exclude the use of destination address modes 0 and 1 for group addressing Questionable whether a 64-bit group would ever be used due to excessive storage and frame occupation, however one case has been identified where a 64-bit address of a device originating a key is used as its identifier

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 7 LB28 comments There are a number of comments for LB28 referring to draft 1 group addressing text which need to be addressed Naturally the outcome of these comments will also affect the resulting text

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 8 Section 7.1 MAC sublayer service specification No need to consider current MLME primitives as group addressing applies to data frames only Currently supports all the parameters required for group addressing: –MCPS-DATA.request TxOptions parameter contains group addressing bit (change option to 0x10, not 0x08) –Text needed to state ack. bit cannot be set as well –MCPS-DATA.indication contains GrpAddress parameter For security process, additional group sequence number can be passed through KeyIdAddress (KeyIdentifier) (see also ) May need to add address mode checking for MCPS-DATA.request

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 9 Section 7.2 MAC frame format Frame control field diagram (figure 35) already supports group addressing Group addressing subfield text already present (section ) Addressing modes table (table 66) will need revising for group addressing support Text describing addressing modes will need revising for group addressing support Data frame MHR text (section ) probably supports group addressing sufficiently

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 10 Section 7.2 MAC frame format (2) Need to ensure frame types other than data frame clearly show group addressing bit is set to 0 Need to specify that data frames using group addressing shall not be acknowledged (section )

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 11 Section 7.3 MAC command frames Draft 1 text supports group addressing in the sense that group addressing does not apply to command frames Need to ensure text is there which states that group addressing bit is set to zero

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 12 Section 7.4 MAC constants and PIB attributes Need to add definition of Destination Address Filter Table (DAFT) Format not decided but will be a lookup table with the same operation in essence as DeviceTable and KeyTable. The lookup operations of DeviceTable and KeyTable are comprehensively described in Could be simplified if address mode is restricted to mode 2 only, i.e. 16-bit only

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 13 Section 7.4 MAC constants and PIB attributes (2) DAFT needs to be optional Default is to have zero entries, and that zero entries means all group addressed frames are silently discarded. This would mean the mechanism to set up the DAFT would be done using unicast or broadcast frames

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 14 Section Transmission Will need revising to accommodate group addressing

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 15 Section Reception and rejection Need to add text to clarify that if the group addressing bit is set, the (data) frame should be processed according to the section which describes using the destination address filter table This section is missing and needs to be added but doesn’t necessarily fit into this section Suggest using the format used in which although arguably terse, is precise and unambiguous

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 16 Section Use of acknowledgements Need to specify that group addressed data frames are not acknowledged This may not be the section to do it in but it should be referenced here

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 17 Section Frame security Sections and need to include text to accommodate the implicit key lookup based on group address if group addressing is specified There will also be a single key sequence number accommodated in a single octet KeyIdAddress (KeyIdentifier) field which is used in addition to the group address for key lookup

doc.: IEEE b Submission March 2005 Robert Cragie, Jennic Ltd.Slide 18 Annex C PICS Needs to indicate clearly that implementation of group addressing is optional If MCPS-DATA.request with group addressing bit in TxOptions set is issued to device which does not support group addressing, it will be rejected using MCPS-DATA.confirm with INVALID_PARAMETER If a frame is received by a device which does not suppport group addressing and the group addressing bit is set, the frame shall be silently discarded