IEEE 802.11-25-0161-00-0arc Protocol Identifier Encoding of EtherType
Explore the encoding of EtherType in Protocol Identifier field according to IEEE standards. Learn about Type 3 and Type 2 PIF encoding methods and the implications of different frame formats. Delve into questions regarding Frame X example and the distinction between LLCs in various scenarios.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
January 2025 doc.: IEEE 802.11-25-0161-00-0arc Protocol Identifier Encoding of EtherType Date: 2025-01-13 Authors: Submission Slide 1 Roger B. Marks, EthAirNet Associates
January 2025 doc.: IEEE 802.11-25-0161-00-0arc Abstract In IEEE Std 802-2024, if EtherType is encoded in a Protocol Identifier using Length/Type encoding, the Protocol Identifier Field (PIF) contains only the EtherType. Submission Slide 2 Roger B. Marks, EthAirNet Associates
doc.: IEEE 802.11-25-0161-00-0arc IEEE Std 802-2024 EtherType is an E-Type Protocol Identifier Can be encoded two ways: o Type 3 PIF encoding, which uses a Length/Type field (as in Ethernet) o Type 2 PIF encoding, which does not use a Length/Type field (RFC 1042 form of SNAP) Submission 3
doc.: IEEE 802.11-25-0161-00-0arc IEEE Std 802-2014 Showed bizarre frame formats, such as: By implication, a simpler form (Form X) was also supported: Form X is inconsistent with each 802-2024 PIF format. Submission 4
doc.: IEEE 802.11-25-0161-00-0arc Why is the Form X example gone? Form X includes a Length , which is specified only within a Length/Type field. A Length/Type field is used only in a Type 3 PIF o Ethernet-like frame To convey an E-type protocol identifier (an EtherType) using a Type 3 PIF, the PIF contains only the EtherType. o figure on prior slide Form X inserts a bunch of bytes before the EtherType. Questions that might arise: o Could one, or should one, or why would one: insert an extra Length-0xAAAA03-0x000000 before the EtherType? Submission 5
doc.: IEEE 802.11-25-0161-00-0arc Question 1: Are the LLCs distinct? Assume Frame 1 arrives with PIF 0x0800 and is sent to an IPv4 protocol stack. Now Frame 2 arrives with PIF Length-0xAAAA03- 0x000000-0x0800. Question 1: Does it go to the same IPv4 protocol stack as Frame 1? Or to a different IPv4 instantiation? Answer: No version IEEE Std 802 has an answer. However, according to 802.1Q, if the frame traverses a Type 2 network, Length-0xAAAA03-0x000000 is stripped. So a frame could be delivered in either form; we cannot rely on the network to accurately demultiplex frames to two separate instances. Submission 6
doc.: IEEE 802.11-25-0161-00-0arc Question 2: Are the delivered frames distinct? Is the intent that the frame passed to the higher-layer protocol (per the EtherType) is formatted to include the Length-0xAAAA03-0x000000, or not include it, depending on how it was sent? For the reason described on the prior page, that s difficult to ensure. This was addressed by IEEE Std 802.1H-1995. A specific list of EtherTypes was specified. For any EtherType on that list, frame were supposed to be delivered retaining the Length-0xAAAA03- 0x000000 encapsulation. Only one EtherType was ever on the list. Submission 7
doc.: IEEE 802.11-25-0161-00-0arc View on 802.1H Per M. Seaman, Protocol identification in 802 LANs : IEEE Std 802.1H-1995, Recommended Practice for Media Access Control (MAC) Bridging of Ethernet V2.0 in IEEE 802 Local Area Networks was created to clarify that EPD encoding of SNAP Identifiers does not include use of 00-00-00 in the OUI portion of the SNAP Identifier. This Recommended Practice was withdrawn at a time when it was felt no longer necessary to address possible confusion on this point. Submission 8
January 2025 doc.: IEEE 802.11-25-0161-00-0arc Conclusion In IEEE Std 802-2024, if EtherType is encoded in a Protocol Identifier using Length/Type encoding, the Protocol Identifier Field (PIF) contains only the EtherType. Submission Slide 9 Roger B. Marks, EthAirNet Associates
