802.1H Revision Project Kevin Nolish Michael Wright
802.1H - Background 802.1H is a recommended practice that concerns bridging interconnected LANs where a mixture of and Ethernet v2.0 traffic is present. It also addresses bridging between LANs with different underlying data links. –Originally Ethernet and Token Ring or FDDI –Today the biggest usage seems to be in
802.1H PAR Highlights Need for the project –802.1H is in need of updating to reflect developments in bridging since publication in 1997 and to correct inaccuracies in the text resulting from changes in other standards. PAR Approval Date : 15 Sep 2006 PAR Expiration Date : 31 Dec 2010 Original Submission Dates –Enter Sponser Ballot : –RevCom Submittal :
Editors Plans Update the Service Model Remove Older Technologies –802.5 –FDDI ? Add new technologies – makes use of RFC1042 and 802.1H as configuration options. Clause of MSDU format Annex M Integration function –Recommends the use of 802.1h Add MIB items Add protocol definition table
PB and PBB bridging What are the implications for technologies that stack tags? –Should 802.1H address such technologies? –Do we have to convert just the outermost tag, or do we have to deal with the entire tag stack? –Presumably VLAN tags behind an I-TAG dont matter. –Does 802.1H apply to S, B, or I components?
Project Schedule Limit the scope of the project to updating the document to those 802 technologies that use 802.1h –Is this satisfactory with 802.1? We will need input from and any other dot group that uses 802.1h
Next Steps Editors active solicit feedback and welcome any input Editors will produce a draft for task group ballot Need active participation of someone from since their standard does make use of 802.1h
Backup Slides
Issues Classifier Type 2 has a VLAN ID –Does this require a similar kind of conversion going between an and interface? Annex M.3 of calls out bridging of VLAN tagged MSDUs between and LANs. –Investigate This Is the WLAN integration service a replacement for bridging? If so 802.1H may not apply.
SNAP Encoded VLAN Tags Apparently on some LANs other than 802.3, the VLAN tag must be carried by a SNAP encoding. –DSAP-AA SSAP-AA CTL-3 –Protocol ID –Followed by VLAN TAG What are these technologies? Are they still relevant? Do we have to do this LLC encoding? Are LLC encoded VLAN tags acceptable on 802.3, thus buying into the rfc 1042 problem, or can we ALWAYS cut out the LLC/SNAP portion of the tag when going to from something else?
The major standard, doesnt mention VLANs. There are other standards regarding interworking with wireless networks, but I think that will not be a problem child. Upon reflection, VLANs in a Personal Area Network are a little odd.
needs to be investigated. Section refers to 802.1Q tagged frames. This is probably OK as this seems to be referring to carrying 802.1Q tagged frames as opposed to having a VLAN concept of its own requiring an LLC/SNAP encoded Vlan TAG.
Diagram Issues What, exactly, are the semantics of the ISO/IEC service model diagrams? –Does the circle represent a lan or an interconnection? –Would these be better off if replaced with a baggy pants style diagram? The editors realize that, generally, illustrating frames is considered a bad idea in 802.1, but it seems to be central to 802.1H.