Donald, I wasn’t intending to show a GLK link variant, just making the minor change to make the example realistic for the standard link case. Think that’s a mistake? (I don’t see any reason LLDP couldn’t run over a non-GLK link. But, then again, we are moving toward desiring/recommending perhaps, a GLK link for any 802.1 protocol, since we know that would work.) Mark From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
Sent: Thursday, May 21, 2015 9:06 AM
To: Mark Hamilton
Cc: Philippe Klein; TGak; John Messenger; Tony Jeffree; Stephens, Adrian P; Glenn Parsons
Subject: Re: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK) Hi Mark, On Thu, May 21, 2015 at 9:49 AM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote: Donald, A nit on your last comment, but I’ll respond broadly as this confuses people often (and could even be argued to be wrong, but it is what it is now): From the table in 8.2.4.1.4, ToDS=0 and FromDS=0 means “A Data frame direct from one STA to another STA within the same IBSS or the same PBSS, a Data frame direct from one non-AP STA to another non-AP STA within the same infrastructure BSS, or a Data frame outside the context of a BSS.” There is no “link local” concept, to an AP, or within an infrastructure BSS at all unless done over a DL.
I was using "link local" in the 802.1 sense. Arguably the term is not a good fit for frames whose source and destination are an AP and a non-AP STA in classic 802.11 because the frames logically do a loop through the DS at the AP. (Although I note the following definition from 802.11-REVmc_D4.0: link: In the context of an IEEE Std 802.11 medium access control (MAC) entity, a physical path consisting of exactly one traversal of the wireless medium (WM) that is used to transfer a MAC service data unit (MSDU) between two stations (STAs).) However, with 11ak, the STAs at the ends of infrastructure communication between an AP and a non-AP STA seem to me to really just be parts of the bridge ports at each end and local communications between them where they are the source and destination does seem to be "link local" and does not loop through the DS so it would seem logical to have it use ToDS = FromDS = 0.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx Mark From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
Sent: Wednesday, May 20, 2015 12:08 PM
To: Mark Hamilton
Cc: Philippe Klein; TGak; John Messenger; Tony Jeffree; Stephens, Adrian P; Glenn Parsons
Subject: Re: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK) Philippe: I was aware of 802.1AB-REV but it hadn't occurred to me that it was impacted by 11k. Thanks for pointing this out. See below: All, What I can find, upon a quick review of the 802.1AB-REV draft: 1. NOTE 1, on page 22, clause 7.3, needs to be softened to say that 802.11 “only sometimes” (or words to that effect) supports Ethertypes natively.
Yeah, perhaps change the first note and preceding paragraph to the following or the like: Where the LLC entity uses an MSAP that is supported by a specific media access control method that does not directly support Ethertype encoding (for example IEEE Std 802.5TM [B3] or IEEE Std 802.11TM [B4] without optional 802.11 direct Ethertype support), the LLDP Ethertype shall be encoded in the octets of LLDPDU header according to the procedures specified in IEEE Std 802 for Subnetwork Access Protocols (SNAP). NOTE 1—The 2005 publication of this standard erroneously stated that IEEE Std 802.11 natively supported Ethertypes. At that time, 802.11 was defined in terms of the use of IEEE Std 802.2 LLC as the native method of addressing for LLC; therefore, Ethertypes were supported only via SNAP encapsulation. Optional native Ethertype support has been added to 802.11 by IEEE Std 802.11ak. 2. We could add more options (more bits) to the System Capabilities TLV, but I’m not sure if there is any need/value in doing that. There is an entry for WLAN Access Point, as Philippe notes. There is also already a bit for a MAC Bridge node. So, for example, does it matter if a node is a non-AP GLK STA, or is it sufficient to say it is a non-AP MAC Bridge? Likewise, is it sufficient to indicate a WLAN access point that is also a MAC Bridge, without need to specify further that it is GLK? That is, is indicating wireless and GLK important?
This is all a judgement call. Given what can be encoded with combinations of bits it is not clear to me that any further bits need to be allocated. 3. Annex C.2 shows an 802.11 frame format, and assumes LDP (and ToDS=0 and FromDS=0, which is not typical). Again, the wording should be softened to note that EDP is an option, and perhaps we should use an example with ToDS or FromDS equal to 1.
Well, it is just showing an LLDP frame which really is link local... I’m not familiar enough with LLDP to be able to answer the questions in #2 above, adequately. Perhaps someone from the 802.1AB community can suggest guidance, and 802.11 experts can respond. Lastly, I’ll note a topic that is just starting discussion (and controversy) within 802.11, which is the question of whether an AP has a local MSAP at all. Clearly, an AP has a management interface, but it can be (and is being) argued that this interface is not directly part of the 802.11 environment, but is instead a non-802.11 higher-layer entity that is co-located on the AP “device”. If this view is followed, it may have impact on how Figure 6-4 in 802.1AB maps to an 802.11 AP, for example. Note that this same concern applies to the PAE (the authenticator, that is) on an 802.11 AP, also, and that is still TBD, so the LLDP agent can probably be considered in that same discussion. Philippe/others, please jump in if you think I’ve missed something in this quick review. Mark Hi Don, Please see the message below from the 802.1AB-Rev Editors. Table 8-4—System capabilities (page 32) includes an entry for “WLAN Access Point” [4] and I guess a new entry for STA GLK will be needed as well. (The discrimination between a GLK and non-GLK capable AP could probably be done by querying the referenced 802.11 MIB isn’t ? ) Could you please have a look and contact either John or Tony ? Thank you /Philippe Hi, Could you alert the 802.11 people to the existence of the 802.1AB-Rev project? There is text in 802.1AB which refers to outdated names for 802.11 architectural components. This would be an opportunity to modernise these and potentially add entries for newer 802.11 components. Please see http://www.ieee802.org/1/files/private/ab-rev-drafts/d0/802-1ab-rev-d0-1.pdf Regards, -- John _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________ |