Hi Mark,
Sorry for the late reply. Yes, I think the LLDP is unrelated to GLK.
But I think it will be good to clearly specify how to handle LLDPUs in both pure GLK nodes network, and mixed GLK with non-GLK nodes network, something like:
1. in pure GLK nodes network, LLDPDUs should be sent using SYNRA with 4-addresses to prevent it loopback to the originator?
2. in the mixed GLK with non-GLK nodes network, LLDPDUs are likely flooded by AP using 3 addresses already, should the AP also flood them using 4-addresses with SYNRA as well?
thx,
huizhao
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
To: 'Huizhao Wang' <h_z_w@xxxxxxxxx>; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Sent: Monday, May 25, 2015 7:58 AM
Subject: RE: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK)
Huizhao,
I agree.
I think that means you agree that Annex C should be changed to show a non-GLK frame, with one of the To/FromDS bits set to one, or we could perhaps show a GLK frame with 4-address and both bits set to 1. Although, I think it is unnecessary, and too early, to be adding GLK frame formats to relatively unrelated standards like this one. Can you confirm that is your intent?
Mark
From: Huizhao Wang [mailto:h_z_w@xxxxxxxxx]
Sent: Saturday, May 23, 2015 12:25 AM
To: Mark Hamilton; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK)
LLDP protocol is very popular for networking discovery purpose (as alternative to Cisco's CDP), for example to find out the immediate neighbors and crawling the network topology through neighbors' neighbors MIB db etc.
Does LLDP need to send over non-GLK link? Yes, it should, in fact, it is usually flooded to the BSS by AP as multicast. If the LLDP is send over GLK link, then it should use 4 addr header with both to-DS/from-DS set 1.
Sorry to be confusing.
Break down (as I got it in my head, at least):
- I said that the Annex C figure should have ToDS or FromDS set to one, as both set to zero is not a typical 802.11 frame, and very unlikely to be what is used for an LLDP frame. (In hindsight, I note that I also said that Annex C verbiage should be softened to allow for EPD format over 802.11, but that was meant to be a completely separate comment, and the close juxtaposition was probably unfortunate.)
- Donald responded that it makes logical sense to him that, over a GLK link, ToDS and FromDS could (maybe even should?) both be zero.
- I responded that my initial comment about what is typical for an 802.11 frame was not in the context of GLK, so whether Donald is right or not, the Annex C frame, which is very likely to be sent over a non-GLK link, should be changed.
- I added the parenthetical as an alternative view, or a guess at a justification for why Donald would have looked at this example with GLK in mind, to note that maybe we should change our view on LLDP, and assume it would in fact be mostly used over GLK links. I left it open as to whether or not to make this viewpoint change. (And, I was way to terse about that.)
So, do we think LLDP makes sense over non-GLK links? I think it does today. Do we think that in the near future (within a year or two of 11ak publication) that LLDP would be frequently or even mostly used over GLK links when used over 802.11? I am not ready with that belief, but I am willing to consider the arguments of others that perhaps are. Thus, my current position would be to change the Annex C example frame format to have ToDS or FromDS set to one.
Mark
-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx]
Sent: Thursday, May 21, 2015 4:19 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)
Hi Mark,
On Thu, May 21, 2015 at 3:44 PM, Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
> 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?
So above you say you are not intending to show GLK, just a classic 802.11 link.
> (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.)
But the parenthetical above sounds like you only want to describe a GLK link.
So I'm a bit confused.
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: 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:
>
>
>
> From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
> Sent: Wednesday, May 20, 2015 2:56 AM
> To: 'Philippe Klein'; STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx; 'John Messenger';
> 'Tony Jeffree'
> Subject: RE: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK)
>
>
>
> 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...
>
>
>
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@xxxxxxxxx
>
>
>
> 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
>
>
>
> From: Philippe Klein [mailto:philippe@xxxxxxxxxxxx]
> Sent: Tuesday, May 19, 2015 2:04 PM
> To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGAK] LLDP considerations for 802.11 (GLK)
>
>
>
> 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
>
>
>
>
>
> From: John Messenger [mailto:jmessenger@xxxxxxxxxxxxxxx]
> Sent: Tuesday, May 19, 2015 10:46 PM
> To: Philippe Klein; Adrian.p.stephens@xxxxxxxxx
> Cc: Glenn Parsons (glenn.parsons@xxxxxxxxxxxx)
> Subject: LLDP considerations for 802.11
>
>
>
> 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
_______________________________________________________________________________
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.