802.1H

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.