1. 802.1H Kevin Nolish Michael Wright

2. 802.1H Project The reason for the update of 802.1H is, primarily, mandated reaffirmation of the standard. As part of the PAR, 802.1H needs to be updated to reflect technological changes since the standard was drafted. –802.5, i.e. token ring, is no longer a standard –802.11 is now the primary customer of 802.1H –Tagging of frames needs to be handled.

3. What 802.1H does Ethernet/802.3 is a data link standard. A data link may support multiple network layer protocols, such as IP, IPX, ARP, whatever. There needs to be a mechanism that demultiplexes a frames contents so that its contents are directed to the proper protocol handler upon reception at a station. These mechanisms are different for different variants of Ethernet and 802.n standards. 802.1H describes how the protocol selection function is modified when transferring a frame between two different 802.n data links.

4. Frame Formats Ethernet 2.0/DIX Frame Format 802.3 Frame Format The key distinction between the frame formats is the utilization of the type/length field In Ethernet 2.0/DIX this contains a 16 bit Ethertype value. Each protocol has a unique value and the IEEE acts as the registrar. In 802.3, this field contains a length. The legal protocol identifiers and the legal frame lengths are cleverly designed so that there is no ambiguity of interpretation for a particular frame.

5. Protocol Indication There are two major mechanisms for protocol indication –EtherType – a 16 bit value that indicates the protocol carried in the frame –LLC/SNAP – a 6 byte header that allows for an 802.2 link layer protocol indication. EtherType is used in Ethernet 2.0/DIX networks. LLC/SNAP is used in 802.3 and 802.11 networks. In practice, most end stations, these days, are agnostic.

6. RFC 1042 – Protocol Interworking RFC 1042 was the first attempt to solve the Ethernet/802.3 interworking issue. Frames transiting to an 802.3 network would have an RFC 1042 header added to them: Frames transiting an Ethernet network would have the RFC 1042 encapsulation removed.

7. RFC 1042 - Issues RFC 1042 does not operate upon LLC encapsulated data. It requires that the frame be LLC/SNAP encapsulated with an EtherType Certain protocols are interpreted differently on an end station depending upon if they are raw EtherType or LLC/SNAP encapsulated. Thus a frame transiting between two Ethernet LANS via an intervening 802.3 LAN would always lose its LLC/SNAP encapsulation, thus changing the meaning of the data flow between the end stations.

8. 802.1H Solution 802.1H Defines the Bridge Tunnel Service The basic concept is that certain protocols are encapsulated using the Bridge-Tunnel encapsulation for transit across an 802.3 network. When bridged to a non-802.3 network, these frames are de-encapsulated before transiting to the non-802.3 network. However, frames with this protocol using the RFC 1042 encapsulation are not de-encapsulated, thus preserving the distinction between LLC/SNAP and raw Ethertype frames across the 802.3 network.

9. The 802.1H-2009 Plan The original intention of the 802.1H work was to simply do a mandatory re-release of the specification while upgrading it for new technologies. –Figures needed to be redone. All figures were lost by the IEEE. –802.5 is no longer a valid standard. Examples using 802.5 need to be changed –References are to ISO versions of IEEE specifications. Normative references need to be changed. –802.11 is the major customer of 802.1H. This should be reflected in the standard.

10. Then Reality Intervened Unfortunately, the problem is uglier than first expected. 802.11 is the major customer of 802.1H. However, their usage model wasnt covered by the original standard. 802.11 in 802.11 Annex M describes the interworking. Theyve extended 802.1H to deal with tagged types. The 802.1H standard needs to be compatible with this de-facto 802.1H implementation.

11. 802.1H New Technical Work Addition of support for tagged frames. –802.1H predated 802.1P, and 802.1Q –Some technologies require LLC/SNAP encapsulation of the tag codewords. 802.11 falls into this category. This requires extensions of the managed objects and service model. –Furthermore, the 802.11 Annex M is not correct with its model of tagged frames. There are errors in 802.11 Annex M that need to be addressed. S Tags are not supported Selective translation table is not in sync with 802.1H

12. Work We Are Not Doing The service model has changed since 802.1H was written. We are not changing the document to reflect the new ISO Layer SAP model. Diagram notation for figures has changed. We simply recreated the old artwork instead of redesigning artwork to fit more modern documentation conventions. 802.1H needs to fit into 802.1 bridges and 802.11 access points. 802.1H could be written to act more as a layer within an ISO stack as opposed to a recommended practice applicable for bridges.

13. 802.1H Procedure We are about to release a draft, 0.1, for task group ballot. The intention is to do comment resolution in March, and depending upon the state of the comments, release an updated document for either task group or work group balloting depending upon the comments received. By the March meeting, we should have a better idea on the timeline of the revision.