Transcript 802.1H - IEEE 802

802.1H
Kevin Nolish
Michael Wright
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.
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
Destination MAC
Address
Source
MAC Address
Ethernet
Type
MAC Data
FCS
MAC Data
FCS
802.3 Frame Format
Destination MAC
Address
Source
MAC Address
Length
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
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.
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:
RFC 1042 Encapsulation LLC/SNAP
SNAP
“AA”
SNAP
“AA”
UI
“03”
SSAP
CTL
Ethernet Tunnel
“00” “00” “00”
Ethernet
Type
Protocol Identifier
• Frames transiting an Ethernet network would have the
RFC 1042 encapsulation removed.
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.
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.
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.
Then Reality Intervened
• Unfortunately, the problem is uglier than first
expected.
• 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
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
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
received.
• By the March meeting, we should have a better
idea on the timeline of the revision.