IEEE-802.11-INT-1-14-2008.pdf
《IEEE-802.11-INT-1-14-2008.pdf》由会员分享,可在线阅读,更多相关《IEEE-802.11-INT-1-14-2008.pdf(14页珍藏版)》请在三一文库上搜索。
1、doc.: IEEE 802.11-07/2248r1 IEEE Standards Interpretation for IEEE Std 802.11 -2007 IEEE Standard for Information technology- Telecommunications and information exchange between systems- Local and metropolitan area networks- Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) a
2、nd Physical Layer (PHY) Specifications Copyright 2008 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved. This is an interpretation of IEEE Std 802.11-2007. Interpretations are issued to explain and clarify the intent of
3、 a standard and are not intended to constitute an alteration to the original standard or to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or port
4、ions of this document must contact the IEEE Standard Department for the appropriate license. Use of the information contained in this document is at your own risk. IEEE Standards Department Copyrights and Permissions 445 Hoes Lane Piscataway, New Jersey 08855-1331, USA November 2008 Interpretation N
5、umber 1: 1-09/07 (TCLAS Elements) Topics: Usage of TCLAS Elements with (Classifier Elements, VLANs, TCP and UDP http:/standards.ieee.org/reading/ieee/interp/802.11-2007.html (1 of 14) 2009/01/06 7:50:31 PM Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under li
6、cense with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 02/02/2009 22:22:52 MSTNo reproduction or networking permitted without license from IHS -,-,- doc.: IEEE 802.11-07/2248r1 protocol) Relevant Clauses: 7.3.2.29 Classification: Ambiguous Interpretation #1 through Interpretation #11 that
7、follow are requested on the following aspects of TCLAS elements, as specified in section 7.3.2.29 of 1: Interpretation Request #1 Issues with Type 0 (Ethernet) TCLAS elements 1. Use of Type field for VLAN unclear a. Can a Type value of 81-00 be used to match all VLAN-tagged frames, per Annex M, or d
8、oes it only apply to the innermost Ethertype field in a frame? Interpretation Response #1 IEEE Std. 802.11-2007 is unambiguous on this matter. The IEEE Std. 802.11-2007 does not apply special meaning to the type value 81-00. From the normative material in Clause 7 of IEEE Std. 802.11-2007, the type
9、value of 81-00 shall match all Ethernet packets with type value 81-00 without further interpretation of the meaning inherent in that value. Interpretation Request #2 b. Can matching on Type be used with singly-encapsulated VLAN frames, i.e. those starting AA-AA-03-00-00-00-81-00 but not starting AA-
10、AA-03-00-00-00-81-00-xx-yy-AA-AA, http:/standards.ieee.org/reading/ieee/interp/802.11-2007.html (2 of 14) 2009/01/06 7:50:31 PM Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 02/02/2009 22
11、:22:52 MSTNo reproduction or networking permitted without license from IHS -,-,- doc.: IEEE 802.11-07/2248r1 per Annex M (which is merely informative)? Interpretation Response #2 IEEE Std. 802.11-2007 is unambiguous on this matter. Clause 7 defines the normative behaviour for TCLAS. Annex M contains
12、 informative information only and does not modify the normative behaviour defined in Clause 7. Interpretation Request #3 2. Use with non-SNAP/non-RFC1042 frames unclear a. Can matching on Type be used with non-RFC1042 SNAP frames, i.e. those starting AA-AA-03 but not starting AA-AA-03-00-00-00, per
13、Annex M? i. If so, does this mean that the first three octets of the SNAP header are simply ignored? ii. If not, does this mean that AppleTalk (2), AppleTalk AARP (1) and IPX Ethernet II, per Table M.2, cannot be matched? b. Can matching on Type be used with non-SNAP frames, e.g. those starting E0-E
14、0-03 or FF-FF, per Annex M? i. If so, how? Interpretation Response #3 IEEE Std. 802.11-2007 specifies how to match the type field of an Ethernet packet without specifying any mapping from an Ethernet packet to a MAC-UNITDATA primitive. Whenever the integration function results in an Ethernet packet,
15、 a TCLAS classifier of Type 0 Ethernet may meaningfully be applied. Whenever an integration function does not result in an Ethernet packet, a TCLAS classifier of Type 0 cannot be applied. http:/standards.ieee.org/reading/ieee/interp/802.11-2007.html (3 of 14) 2009/01/06 7:50:31 PM Copyright The Inst
16、itute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 02/02/2009 22:22:52 MSTNo reproduction or networking permitted without license from IHS -,-,- doc.: IEEE 802.11-07/2248r1 Interpretation Request #4 Issues with
17、 Type 1 (TCP/UDP IP) TCLAS elements 1. Use of Version field unclear a. Is the Version field part of the Classifier Mask, such that the LSB of the Classifier Mask refers to the Version, or does the LSB of the Classifier Mask refer to the Source IP Address? b. Is the Version field required to be set t
18、o 4 for IPv4 or 6 for IPv6 (even if the answer to the previous question is that the LSB of the Classifier Mask refers to the Version and hence the Version may not be part of the matching), or is the IP version to which a Type 1 TCLAS element applies implied by the length of the TCLAS element? Interp
19、retation Response #4 1a) IEEE Std. 802.11-2007 is unambiguous on this matter. The version field is included in the list of classifier parameters paragraph 4 page 137 and is therefore included in the classifier mask subfield as defined in paragraph 1 page 137. 1b) IEEE Std. 802.11-2007 is unambiguous
20、 with respect to the fields included in the Frame Classifier. IEEE Std. 802.11-2007 is ambiguous with respect to the value contained in those fields. Specification of those values is outside the scope of IEEE Std. 802.11-2007. IEEE Std. 802.11-2007 is ambiguous on this issue. The issue will be forwa
21、rded to the 802.11 Working Group for consideration in a future revision of the standard. Interpretation Request #5 http:/standards.ieee.org/reading/ieee/interp/802.11-2007.html (4 of 14) 2009/01/06 7:50:31 PM Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under
22、 license with IEEELicensee=HP Monitoring/1111111164 Not for Resale, 02/02/2009 22:22:52 MSTNo reproduction or networking permitted without license from IHS -,-,- doc.: IEEE 802.11-07/2248r1 2. Lack of Protocol field for IPv6 a. It is not possible to match based on the upper-layer protocol in IPv6 fr
23、ames, unlike in IPv4 frames. Is this an oversight, or is it deliberate? Interpretation Response #5 2a) IEEE Std. 802.11-2007 is unambiguous on this issue. The next header field is not included in the IPv6 Frame Classifier. This issue will be forwarded to the 802.11 Working Group for consideration in
24、 a future revision of the standard. 3. Lack of DSCP field for IPv6 a. It is not possible to match based on the DSCP in IPv6 frames, unlike in IPv4 frames. Is this an oversight, or is this deliberate? 3a) IEEE Std. 802.11-2007 is unambiguous on this issue. The Traffic Class field is not included in t
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IEEE 802.11 INT 14 2008
链接地址:https://www.31doc.com/p-3773394.html