The reason for the update of 802.1H is,
primarily, mandated reaffirmation of the
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.
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 frame’s 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.
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.
There are two major mechanisms for protocol
a 16 bit value that indicates the protocol
carried in the frame
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
In practice, most end stations, these days, are
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.
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
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
encapsulated before transiting to the non
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.
The original intention of the 802.1H work was to
simply do a mandatory re
release of the
specification while upgrading it for new
Figures needed to be redone. All figures were lost by
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
802.11 is the major customer of 802.1H. This should
be reflected in the standard.
Then Reality Intervened
Unfortunately, the problem is uglier than first
802.11 is the major customer of 802.1H.
However, their usage model wasn’t covered by
the original standard.
802.11 in 802.11 Annex M describes the
interworking. They’ve extended 802.1H to deal
with tagged types.
The 802.1H standard needs to be compatible
with this de
facto 802.1H implementation.
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
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
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
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
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
By the March meeting, we should have a better
idea on the timeline of the revision.