IEEE C802.16maint-05/091. IEEE Broadband Wireless Access Working Group <

Transcription

1 Project Title Date Submitted IEEE Broadband Wireless Access Working Group < Definition of octets present in VLAN Convergence Sublayer Source(s) Mike Geipel Axxcelera 1600 East Parham Road Richmond VA Voice: Fax: mai1to: ieee,org Re: Working group letter ballot 17, call for comment on P80216_Cor1_D1.pdf dated Abstract Purpose Notice Release Patent Policy and Procedures Definition of octets present in VLAN Convergence Sublayer. Available to support a comment in the commentary database. This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with the IEEE Patent Policy and Procedures < including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <mailto:chair@wirelessman.org> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. The Chair will disclose this notification via the IEEE web site < 0

2 Definition of Octets Present in VLAN Convergence Sublayer Mike Geipel Axxcelera Purpose The purpose of this document is to contain diagrams needed to for discussion of VLAN format issues, in support of a comment made in response to a call for corrigenda comments, as noted above. Background Presumably, the motivation for an IP CS was to provide for sources / destinations of IP traffic that do not necessarily exist on a LAN. One example of this might be a laptop with an IP stack, but no need for an independent MAC address. Another example could be an SS that is a NAT router. IP packets are well-defined, so in these cases, the overhead of Ethernet or encapsulation would be an unnecessary waste of bandwidth. The PDU could simply be the IP packet. There is no definition for a VLAN MAC layer, as one would expect from a CS name like IP-over Q/VLAN. VLANs are mapped onto each MAC layer to include the two byte TPID. (Such a mapping has not yet been defined for messages over transport connections.) 801.1Q does, however, define a standard two-byte TCI that contains the user priority and VLAN identifier. VLANs are used to limit the broadcast domain of traffic. Multiple IP CS services (for example) may legitimately be presented to different VLANs to limit their visibility. So I assume that the intent of the VLAN CS would be to remove the unneeded overhead of DA, SA and TPID. Example According to the standard, an 802.3/Ethernet frame may be either tagged, or untagged. Here is the Ethernet example: 1

3 Ethernet Frame (not 802.3) Ethernet Hdr FCS Untagge d DA SA Ether or Tagged DA SA Ethernet TPID TCI Ether 2 bytes: This is one of the reasons that I proposed in a previous comment that / Ethernet CS should support VLAN classifiers. IEEE It bears repeating: The standard specifies that 802.3/Ethernet frames may be tagged or untagged. 2

4 This was snipped from the specification, for a tagged Ethernet frame. Tagged Control Information (TCI). This two byte structure contains the additional information needed to support VLANs. It is the same format for all 802 mappings. Untagged Frames Note that the VLAN classifiers are defined such that they cannot match untagged frames. Untagged Ethernet Frame containing an IP packet Ethernet Hdr Ethernet Frame (not 802.3) FCS 802.3/Ethernet DA SA Ether FCS* Ethertype is: 0x0806 for IPv4, or 0x86DD for IPv6 IP CS content (The box labeled FCS* is drawn this way for 802.3/Ethernet CS, since we have not defined yet whether it is there or not has an equivalent CRC, but its use is optional). 3

5 Tagged Ethernet Frame containing an IP packet Ethernet Frame (not 802.3) Ethernet Hdr FCS 802.3/Ethernet DA SA Ethernet TPID TCI Ether 2 bytes: 81- Ethertype is: 0x0806 for IPv4, or 0x86DD for IPv6 FCS* VLAN TCI Ether IP CS content.the Ether is still there as protocol discriminator. Of course, in the more likely cases may be IPv4-over- VLAN or IPv6-over-VLAN, where the encapsulated layer-3 protocol is already know Tagged Frames with LLC/SNAP Encapsulation 4

6 Tagged IEEE802.3 Frame containing an IP packet IEEE802.3 Frame (not Ethernet) Hdr FCS 802.3/Ethernet DA SA SNAP TPID TCI Ether 8 bytes: FCS* SNAP Hdr: AA-AA-03 SNAP Pid: Tag : Ethertype is: 0x0806 for IPv4, or 0x86DD for IPv6 VLAN TCI Ether IP CS content Note that the VLAN frame that is left over, after Ethernet s DA, SA and TPID were stripped off, is the same as in the previous example. Non-Sequitur Of course, there are other, related, formats used to encode Here is a diagram to show the intended use of the media-independent (LLC) encapsulation when frames are bridged between dissimilar MAC ports, without the involvement of VLAN tagging. 5

7 This snippet came from an older specification. Notice that the PID = (OUI, Ether)! I believe that this is the same approach that has taken. Other Old Formats The length-encoded versions may have been called the IEEE802.2 format, or something like that: DA, SA, Length, PID=Ether, Data, FCS DA, SA, Length, SNAP=(DSAP, SSAP, UI), PID=OUI, Data, FCS There is a raw format, no longer widely in use which used DSAP and SSAP octets equal to 0xFF. There is other encoding too. Fortunately, most of them have fallen out of favor. For Fun I don t even pretend to understand all the cases in this example from 802.1Q-2002: 6

8 Whew! Remaining Issues So, how many of these cases should our Ethernet/VLAN classifiers support? What further clarification is needed for both Ethernet and VLAN classifiers? Note also that RFC1042 defined various mappings for ARP Since the Ether is available to us in the proposed mapping We can define a mapping for ARP on VLAN CS. (No text provided at this time.) Closing Remarks The current spec does not define what octets are delivered for VLAN CS frames. Given the current use of 802.3/Ethernet, a simple approach would be to prepend the IP frame with the TCI and the Ether, as follows: TCI Ether MAC Payload This does not yet define an ARP mapping, but that can be handled later, once this is settled. Suggestions? 7