From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Friday, September 13, 2019 at 9:04 AM
To: "Cordeiro, Carlos" <carlos.cordeiro@xxxxxxxxx>, Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>, "Qi, Emily H" <emily.h.qi@xxxxxxxxx>, "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>, Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
Hello,
Here is the version with the issues fixed, and the addition of the
stuff that was TBD:
Discussion:
The Multi-band element is huge. We should not be using this to carry just three octets of information.
Proposed changes:
In D2.4:
Add the following subclause:
9.4.2.xx OCT Source element
The OCT Source element is used to specify the MLME that is the source of an OCT MMPDU. The format of the OCT Source element is shown in Figure 9-xxx.
Element ID
Length
Element ID Extension
Band ID
Channel Number
BSSID
Octets:
1
1
1
1
1
6
Figure 9-xxx—OCT Source element format
The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
The Band ID field identifies the band on which the source MLME operates, as defined in Table 9-69 (Band ID field).
The Channel Number field contains the channel number on which the source MLME operates.
The BSSID field contains the BSSID of the BSS in which the source MLME operates.
Add the following row to Table 9-94—Element IDs at the correct position for the Element ID Extension (probably just before the last row):
OCT Source (see 9.4.2.xx (OCT Source element))
255
<ANA>
Yes
No
and modify the last row (Reserved) to not include <ANA> in the third column (Element ID Extension).
Change as follows:
6.3.89.2.2 Semantics of the [MLME-OCTunnel.request] service primitive
The primitive parameters are as follows:
MLME-OCTunnel.request(
PeerSTAAddress,
OCT MMPDU,
Multi-band peer,
Multi-bandOCT source(M70)(#2631))
Multi-bandOCTsource(M70)(#263
1)
Multi-bandOCT Sourceelement
As defined in the
Multi-bandOCT Sourceelement format (see 9.4.2.
138
(Multi-band element)xx (OCT Source element))The
Multi-bandOCT Source element identifies theMLME entity that generated (i.e., is the
source) of the OCT MMPDU.
6.3.89.3.2 Semantics of the [MLME-OCTunnel.indication] service primitive
The primitive parameters are as follows:
MLME-OCTunnel.indication(
PeerSTAAddress,
OCT MMPDU,
Multi-band local,
Multi-bandOCT source,(M70)(#2631)Tunneled RXVECTOR(M70)
)
Multi-bandOCTsource(M70)(#263
1)
Multi-bandOCT Sourceelement
As defined in the
Multi-bandOCT Sourceelement format (see 9.4.2.
138
(Multi-band element)xx (OCT Source element))The
Multi-bandOCT Source element identifies theMLME entity that generated (i.e., is the
source) of the OCT MMPDU.
9.6.20.7 On-channel Tunnel Request frame format
Table 9-484—On-channel Tunnel Request frame Action field format
5(M70)
Multi bandOCT Source
(M70)The
Multi-bandOCT Source field containsthe Multi-bandan OCT Source element that identifies the MLME that is the source of an OCT MMPDU.The values of the Band ID, Channel Number and BSSID fields contained in this element are used to identify the MLME within the STA.
11.32.5 On-channel Tunneling (OCT) operation
(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element or OCT Source element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.
(M70)Except for the following cases, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element or OCT Source element are used by an NT-MLME to deliver messages to a TR-MLME through the OCTunnel.request primitive, and are used by a TR-MLME to deliver messages to an NT-MLME through the OCTunnel.indication primitive:
(#2200)An NT-MLME receiving an OCT MLME request primitive shall
— As defined in this standard, process the request and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the peer Multi-band element and the
Multi-bandOCT source parameter set(#2631) to theMulti-bandOCT Source element identifying the NT-MLME.(M70)
A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the
Multi-bandOCT source parameter(#2631) set to the value of theMulti-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame(M70). The MLME-OCTunnel.indication primitive shall be generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.
(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive shall
— As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air, with the exception that an (#2591)acknowledgment, if any, shall not be sent as a response to the reception of the MMPDU.(M70)
— Generate an OCT MLME indication primitive, if one is defined, corresponding to the frame type of tunneled MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as defined in this standard. The Multi-band local parameter of the OCT MLME indication primitive shall be set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter shall be set to the value of the
Multi-bandOCT source parameter(#2631) of the MLME-OCTunnel.indication primitive.(M70)
(#2200)An NT-MLME receiving an OCT MLME response primitive, (M70)if one is defined, or generating a response by itself, if no OCT MLME response primitive is defined (e.g., MLME-SCAN.response is not defined), shall
— As defined in this standard, process the response and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the the peer Multi-band element and the
Multi-bandOCT source parameter(#2631) set to the Multi-band element identifying the NT-MLME. If no OCT MLME response primitive is defined, the Multi-band peer parameter shall be set to the value of theMulti-bandOCT source parameter(#2631) received in the corresponding MLME-OCTunnel.indication primitive. The MLME-OCTunnel.request primitive shall be generated to the TR-MLME identified by the local Multi-band element specified in the OCT MLME response primitive, if one is defined, or to the TR-MLME identified by the Multi-band local parameter of the MLME-OCTunnel.indication primitive that triggered this response, if no OCT MLME response primitive is defined.(M70)
A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the
Multi-bandOCT source parameter(#2631) set to the value of theMulti-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame.(M70) The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.
(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive
— Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air.
— Generates an OCT MLME confirm primitive, if one is defined, corresponding to the frame type of the tunneled MMPDU. This primitive is directed at the SME and has the Multi-band local parameter set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter set to the value of the
Multi-bandOCT source(#2631) parameter of the MLME-OCTunnel.indication primitive. If the OCT MLME confirm primitive is the MLME-SCAN.confirm primitive and the NT-MLME did not scan all the channels specified in the corresponding MLME-SCAN.request primitive, the ResultCode parameter in the MLME-SCAN.confirm primitive shall be set to PARTIAL_SCAN and the ScannedChannelList parameter shall list all channels that have been scanned.(M70)
Proposed resolution:
REVISED
Make the changes shown under “Proposed changes” for CID 2634 in <this document>, which introduce an OCT Source element to ensure unnecessary octets are not transmitted.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Mark Rison
Sent: 13 September 2019 07:54
To: 'Cordeiro, Carlos' <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
Hello Carlos,
Thanks for the review.
- I see occurrences of “OCT element” which is something that does not exist.
I find one occurrence -- where are the others?
That occurrence should of course be "OCT Source element".
- There is a paragraph in (11.32.5 On-channel Tunneling (OCT) operation) that reads: “(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.” However, now you have a new element. How are those fields set? How would this paragraph be changed to reflect the new element?
Ah, yes, thanks. That can just become;
To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in the OCT Source element are used to identify an MLME.
This resolution has problems as it is. A more thorough scrubbing is needed.
OK, well please perform this scrubbing ASAP, since I think Dorothy
is extremely keen that all TGm comments be resolved by the end
of next week!
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Sent: 13 September 2019 01:27
To: Mark Rison <m.rison@xxxxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
I need to review this further. However, after a quick review:
- I see occurrences of “OCT element” which is something that does not exist.
- There is a paragraph in (11.32.5 On-channel Tunneling (OCT) operation) that reads: “(M70)To perform the OCT procedure, the values of the Band ID, Channel Number and BSSID fields in a Multi-band element are used to identify an MLME. All other fields in the Multi-band element shall be reserved.” However, now you have a new element. How are those fields set? How would this paragraph be changed to reflect the new element?
This resolution has problems as it is. A more thorough scrubbing is needed.
Thanks,
Carlos.
From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, September 12, 2019 12:27 PM
To: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
Hello,
I haven't received any feedback on this, so I'm going to presume people
are happy with this direction and I just need to do the stuff in yellow
below.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Mark Rison
Sent: 29 August 2019 19:00
To: 'Cordeiro, Carlos' <carlos.cordeiro@xxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
OK, here's what I've thrown together quickly:
Discussion:
The Multi-band element is huge. We should not be using this to carry just three octets of information.
Proposed changes:
In D2.4:
Add the following subclause:
9.4.2.xx OCT Source element
The OCT Source element is used to specify the MLME that is the source of an OCT MMPDU. The format of the OCT Source element is shown in Figure 9-xxx.
Element ID
Length
Element ID Extension
Band ID
Channel Number
BSSID
Octets:
1
1
1
1
1
6
Figure 9-xxx—OCT Source element format
The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).
The Band ID field identifies the band on which the source MLME operates, as defined in Table 9-69 (Band ID field).
The Channel Number field contains the channel number on which the source MLME operates.
The BSSID field contains the BSSID of the BSS in which the source MLME operates.
TBD: Add the element to the element table, as extensible but not fragmentable
Change as follows:
9.6.20.7 On-channel Tunnel Request frame format
Table 9-484—On-channel Tunnel Request frame Action field format
5(M70)
Multi bandOCT Source
(M70)The
Multi-bandOCT Source field containsthe Multi-bandan OCT Source element that identifies the MLME that is the source of an OCT MMPDU.The values of the Band ID, Channel Number and BSSID fields contained in this element are used to identify the MLME within the STA.
11.32.5 On-channel Tunneling (OCT) operation
(#2200)An NT-MLME receiving an OCT MLME request primitive shall
— As defined in this standard, process the request and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the peer Multi-band element and the
Multi-bandOCT source parameter set(#2631) to theMulti-bandOCT element identifying the NT-MLME.(M70)
A TR-MLME receiving an On-channel Tunnel Request frame shall generate an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the
Multi-bandOCT source parameter(#2631) set to the value of theMulti-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame(M70). The MLME-OCTunnel.indication primitive shall be generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.
(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive shall
— As defined in this standard, process the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air, with the exception that an (#2591)acknowledgment, if any, shall not be sent as a response to the reception of the MMPDU.(M70)
— Generate an OCT MLME indication primitive, if one is defined, corresponding to the frame type of tunneled MMPDU. This primitive is generated to the SME of the STA, which processes the MMPDU as defined in this standard. The Multi-band local parameter of the OCT MLME indication primitive shall be set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter shall be set to the value of the
Multi-bandOCT source parameter(#2631) of the MLME-OCTunnel.indication primitive.(M70)
(#2200)An NT-MLME receiving an OCT MLME response primitive, (M70)if one is defined, or generating a response by itself, if no OCT MLME response primitive is defined (e.g., MLME-SCAN.response is not defined), shall
— As defined in this standard, process the response and construct an OCT MMPDU corresponding to the primitive in question. The NT-MLME shall not transmit any frame as a result of this primitive.
— Generate an MLME-OCTunnel.request primitive with parameters including the OCT MMPDU, the Multi-band peer parameter set to the the peer Multi-band element and the
Multi-bandOCT source parameter(#2631) set to the Multi-band element identifying the NT-MLME. If no OCT MLME response primitive is defined, the Multi-band peer parameter shall be set to the value of theMulti-bandOCT source parameter(#2631) received in the corresponding MLME-OCTunnel.indication primitive. The MLME-OCTunnel.request primitive shall be generated to the TR-MLME identified by the local Multi-band element specified in the OCT MLME response primitive, if one is defined, or to the TR-MLME identified by the Multi-band local parameter of the MLME-OCTunnel.indication primitive that triggered this response, if no OCT MLME response primitive is defined.(M70)
A TR-MLME receiving an On-channel Tunnel Request frame generates an MLME-OCTunnel.indication primitive with the Multi-band local parameter set to the Multi-band element identifying the TR-MLME, the
Multi-bandOCT source parameter(#2631) set to the value of theMulti-bandOCT Source field contained in the On-channel Tunnel Request frame and the Tunneled RXVECTOR parameter set to the RXVECTOR of the On-channel Tunnel Request frame.(M70) The MLME-OCTunnel.indication primitive is generated to the NT-MLME identified by the peer Multi-band element contained within the received On-channel Tunnel Request frame.
(#2200)An NT-MLME receiving an MLME-OCTunnel.indication primitive
— Processes the OCT MMPDU parameter of the primitive as if the MMPDU had been received over the air.
— Generates an OCT MLME confirm primitive, if one is defined, corresponding to the frame type of the tunneled MMPDU. This primitive is directed at the SME and has the Multi-band local parameter set to the value of the Multi-band local parameter of the MLME-OCTunnel.indication primitive and the Multi-band peer parameter set to the value of the
Multi-bandOCT source(#2631) parameter of the MLME-OCTunnel.indication primitive. If the OCT MLME confirm primitive is the MLME-SCAN.confirm primitive and the NT-MLME did not scan all the channels specified in the corresponding MLME-SCAN.request primitive, the ResultCode parameter in the MLME-SCAN.confirm primitive shall be set to PARTIAL_SCAN and the ScannedChannelList parameter shall list all channels that have been scanned.(M70)
TBD: In Clause 6 change “Multi-band source” to “OCT source” (or other way round for the .ind).
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Sent: 29 August 2019 18:21
To: Mark Rison <m.rison@xxxxxxxxxxx>; Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
The spec uses the terms Multi-band peer parameter, Multi-band local parameter and Multi-band Source parameter in 11.32.5 and also in the primitives. As such,
> I'll just create a new extensible element containing the three things that are said to identify a source MLME (Band ID, Channel Number, BSSID -- note Mike that the operating class is not among these) and plumb it into 9.6.20.7 On-channel Tunnel Request frame format
… it is not evident to me how restricting the change to the above will bring consistency with the other parts in the spec. With that said, personally, I am open minded and look forward to seeing the proposed changes.
Thanks,
Carlos.
From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, August 29, 2019 7:07 AM
To: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>; Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: RE: TGmd - CID2634
Hello,
Well, I don't propose to make all the
primitives in clause 6.3, text in 11.32.5 and figures (e.g., figures 11-53 and 11-54), etc....
changes only to be told the group doesn't want to make a change.
I'll just create a new extensible element containing the three things
that are said to identify a source MLME (Band ID, Channel Number, BSSID
-- note Mike that the operating class is not among these) and plumb it
into 9.6.20.7 On-channel Tunnel Request frame format. Then people can
look at that. The other changes will just follow trivially.
Thanks,
Mark
P.S.: Figures 11-53 and 11-54 appear not to be searchable, unlike other
figures. Can the Editors please ensure that it is searchable in future
drafts, please?
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>
Sent: 28 August 2019 18:36
To: Qi, Emily H <emily.h.qi@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Mark Rison <m.rison@xxxxxxxxxxx>; Cordeiro, Carlos <carlos.cordeiro@xxxxxxxxx>
Cc: Dorothy Stanley <dstanley1389@xxxxxxxxx>; Jon Rosdahl <jrosdahl@xxxxxxxx>
Subject: Re: TGmd - CID2634
Thanks Emily,
So we would need Mark R to create and post a submission and Mark H to post a link to the document to the 802.11 reflector to obtain WG member feedback.
Cheers,
Mike
From: "Qi, Emily H" <emily.h.qi@xxxxxxxxx>
Date: Tuesday, August 27, 2019 at 8:41 PM
To: "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx>, Mark Rison <m.rison@xxxxxxxxxxx>, "Cordeiro, Carlos" <carlos.cordeiro@xxxxxxxxx>
Cc: Michael Montemurro <mmontemurro@xxxxxxxxxxxxxx>, Dorothy Stanley <dstanley1389@xxxxxxxxx>, Jon Rosdahl <jrosdahl@xxxxxxxx>, "Qi, Emily H" <emily.h.qi@xxxxxxxxx>
Subject: TGmd - CID2634
Hello Mark and Mark,
I have talked to Carlos on CID 2634. Carlos isn’t aware of any implementation in the field. Including Carlos here...
If we decide to go with the direction that Mark R proposed in the proposed resolution, someone (perhaps, Mark H ? ) should an email to the reflector and see whether there is any objection.
Also, a submission is required because we need to make changes to many places. For example, primitives in clause 6.3, text in 11.32.5 and figures (e.g., figures 11-53 and 11-54), etc....
Regards,
Emily
