volleyballbeginnerNetworking and Communications

Oct 27, 2013 (3 years and 5 months ago)



Kevin Nolish

Michael Wright

802.1H Project

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.

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.

Protocol Indication

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

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.

RFC 1042


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 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
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 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

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

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
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.

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

By the March meeting, we should have a better
idea on the timeline of the revision.