This note contains a capture of an e-mail discussion between Mick Seaman and myself regarding issues with the v0.3 version of 802.1h-2009. These were posted with Mick's permission and will be referred to by specific comments against the v0.3 draft submitted by Kevin Nolish. Kevin, Further thought. I should have said how you can get over the difficulty of not wanting to add extra parameters to the ISS, and yet make everything work with the bridges we have at the moment. You simply use what would be the Ethernet frame format in the mac_service_data_unit, i.e. if the first two octets encode a number greater than the longest legal length value for the 802.3 Type/Length field then what is being requested is "EtherType Protocol Identification", otherwise what is being requested is "LLC Protocol Identification". Then you could, if you wanted, modify the subclauses called out by clause 6.7 (Support of the Internal Sublayer Service by specific MAC procedures) and hey presto you have changed 802.1D from a "MAC Bridge specification" to an "Ethernet/LLC Bridge specification" and 802.1Q from specifying "VLAN-aware MAC Bridges" to "VLAN-aware Ethernet/LLC". The change even works for TPMRs, allowing them to change MAC types. The downside of this "trick" is that the resulting bridge can't bridge any frame using "LLC Protocol Identification" that is longer than the legal Ethernet frame length between any two interfaces, even if they were both used LLC encoding for everything (say two Token Rings). However you clearly could use the trick to specify your shim effect with no mods to the ISS for 2 address stuff. If (big IF) the only 802.11 differences were in the addresses then the trick clearly works for 802.11 as well. You just need an ISS equivalent for 802.11, but as I said I don't think that is 802.11's job. In any case you don't need a service interface with a "protocol mechanism" parameter, because all that is is specifying encoding so the stuff supporting the interface can just get what it need to work out the encoding. Mick ----- Original Message ----- From: Mick Seaman To: Kevin Nolish Cc: Tony Jeffree ; Steve Haddock ; Michael Wright Sent: Thursday, May 14, 2009 2:22 PM Subject: Re: 802.1H Ballot Kevin, The mistake made by the designers of Appletalk was a perfectly natural one, given the information avaialable to them was largely couched in terms of an "standard" encoding to support EtherTypes over 802 Networks, but is hard to describe consistently as a "service" given where we are today with the support of EtherType protocol identification on 802.3 and other 802 MACs. The essential thing about a "service" in the OSI sense is that it expresses the relationship between communicating peers, not just that it is a convenient description for layering interfaces within a single system with details that are purely locally specific removed. The Appletalk Phase 2 decision about how to encode frames with the assigned Appletalk EtherType on 802.3 LANs was essentially just that, an encoding decision. Given the wide deployment of Phase 2 and the desire of bridge manufaturers to successfully bridge between the different types of LAN it was bridge's that had to provide the fix. So the set problem was to provide two services, A and B, to Appletalk Phase 2 and Phase 1 respectively, with the services defined in terms of the following properties: A. Make Appletalk Phase 1, encoded with simple EtherType on 802.3, turn up on a remote Ethernet (after bridging) encoded with just that EtherType. So that would look exactly like the EtherType protocol identification service we have today, except the service is only available to stations directly attached to 802.3. B. Make Appletalk Phase 2 use the encoding that would be used for EtherTypes on non-802.3 media everywhere (including on 802.3). So from the point of view of our current protocol identification service, B looks like EtherType protocol identification on non-802.3 media, and like no other known service on 802.3, while A looks like a perfectly reasonably encoded service on 802.3 but is strange everwhere else. Essentially A and B are the two services that are used by Appletalk. BTE is not a "service" at all, it is a way of encoding service B on non-802 media. Using RFC 1042 on 802.3 is also not a service at all, it is a way of encoding service A on 802.3 (it is also used to encode service A on non-802.3, and regular EtherType protocol identification on non 802.3) So if you want to try to use more than two "services" to provide a rigorous description of what is going on you are going to end up with 6 items to label, not just 2. Mick ----- Original Message ----- From: Mick Seaman To: Kevin Nolish Cc: Tony Jeffree ; Steve Haddock Sent: Thursday, May 14, 2009 12:58 PM Subject: Re: 802.1H Ballot Kevin, I have read through your note on the difficulties of using service interfaces, and I believe I have answers to all points with the possible exception of 802.11 (where I don't have the background and where they may have already made additional mistakes with 1H-REV could only serve to point out, not to fix if such mistakes cause inherent contradictions). I believe that one should first get the model straight without the 802.11 complicatons, then it may be obvious what to do formally with 802.11 or one might have to say something like "like that over there" remember that 802.11 modelling as a bridge is not a solved problem yet. Norm has had multiple goes at it and has failed to get it right yet. Don't try and do it "en passant", not only will you fail you will also fail to get the case for other media done for 1H-REV. Whetehre or not 802.11 is a major use of this practice you can't fix the bridging of 802.11 using this as a lever. I agree about the mess that is possible to create using a hierarchy of service interafces. It can be done but it is necessary to do it without the hierarchy first, and then you will discover how to make the hierarchy handle the cases (but it is not necessary to do that for 1H). The rest is conversation for the bar. My major point is that you should not consider this functionality as an "H shim", that way you get back into the hierarchy of interfaces problem. That way, as you show below you get back into there being a control that says EtherType or 1042 or BTE or LLC. Wrong way to go, all thats happened is that a clumsy formalism is being used to express four encoding choices that are directly derived from the "EtherType" or "LLC protocol identification" choice. The only place these choices are made is where the ISS is being directly supported by the MAC, that's a major point. Mick ----- Original Message ----- From: Kevin Nolish To: Mick Seaman Cc: tony@jeffree.co.uk Sent: Thursday, May 14, 2009 12:14 PM Subject: RE: 802.1H Ballot Don't bother with excel. You've done far more than I asked for and could have reasonably expected. I will incorporate this into my own comments. Do you have objections if I submit your notes to the web site? That will allow me to express my comment as: Update section 1.2 along the lines of Mick's suggestions documented in 802-1h-knolish-0509-v01-. This does make your commentary public and I don't want to do that without your permission. We should talk about expressing H in terms of the service sublayer interfaces. I will buy the beer or whatever poison you prefer. I thought about expressing 802.1H behavior in terms of the usual service model and ran into some issues. First, 802.1H is not a function of the relay, thus the ISS for D bridges, EISS for Q & friends, do not seem to be the proper service interfaces. In particular, the operation of 802.1H requires knowledge of the requirements of the LAN attached to the egress port. Thus 802.1H seems to belong in the Media Specific portion of the "baggy pants leg".. This is below the MAC interface, thus the ISS is not the correct choice for the upper layer of the 802.1H "shim". Further note that neither the ISS nor the EISS have the proper parameters as the information that we need to make decisions on is buried in the user data "parameter" of the (E)ISS. Contaminating the ISS or EISS with extra encapsulating information seemed to be the wrong way to go as this would complicate pretty much all of D and Q for what is, essentially, a 3 page recommended practice. Furthermore, 802.1H is used in 802.11 access points and, theoretically, could be used in other 802.X technologies. This is another reason why I considered and rejected an extension of the (E)ISS. H is used in places other than bridges, so modeling the functionality in the relay or in terms of interactions with the relay would tend to divorce the recommended practice from reality. For better or worse 802.11 access points are the major users of this standard. Also, one cannot model the 4 address form of 802.11 frames using the (E)ISS. Michael and I did attempt to reformulate 802.1H in terms of the service model, but we ran into trouble. I now believe that this modeling is possible as your e-mail provided a way around the issues that we ran into. What I wound up with when I attempted to formally model H operation was quite messy, although I now think that this was because I tried to express the parsing algorithm in terms of service sublayer interfaces. Upon reflection upon your text, I believe that where I went into the weeds was that I attempted to express the parsing of the frame in terms of a hierarchy of service interfaces with a tree-like structure to reflect the possibilities. It looked something like: Request at H-SS causes a request at one of the following interfaces H-SS + Ethertype - for frames using Ethertype with No LLC H-SS + DSAP + SSAP + OP - for frames using LLC A request at the LLC then caused indications at another level of service interfaces H-SS + DSAP + SSAP + OP - for frames without protocol indications H-SS + DSAP + SSAP + OUI + Protocol - for frames using protocol ids The H encoding function wound up with a lot of upper layer interfaces of differing parameter signatures, one of which would have a request operation for each frame request seen at the H-SS layer. The differing operations allow the encoding layer to do the right thing based upon the received encapsulation. At this point, we had an H shim with about 1/2 dozen service interfaces sitting below a hierarchy of functional blocks whose purpose was to tear apart the protocol information in a frame all interconnected via a hierarchy of service interfaces. Our reaction was "I don't think so", although we expressed it in a somewhat more crude and vulgar fashion. Two words, rhyming with "truck" and "hat". Now, if I can "informally" express the parsing portion as you did below, moving to a service model scheme seems likely, although there is one issuse that remains. The EISS/ISS service models assume a two address frame. This causes issues with H as H needs to fit into both 802.1 bridges and 802.11 access points. What I wound up with, and I still think is correct, is an HSS that looks something like HSS.request(Prelude : octet stream Protocol_Mechanism : ( EtherType, 1042, BTE, LLC ) EtherType : 16 bits ( validity of parameter depends upon mechanism ) User_Data : octet stream Checksum : 32 bits ) The point of the Prelude is that the H "shim" in the MAC stack really doesn't care if the frame starts with 802.3 D-MAC S-MAC addresses if it starts with the 4 address 802.11 frame header, or something else. My thought had been to put the H-shim in the MAC stack above the layer in the MAC stack that performs media conversion, thus the description would fit into either 802.1 bridges or 802.11 access points without needing to be aware of the physical nature of the frames. The H-Shim needs to know about the requirements of the underlying MAC regarding the representation of protocol type information, but that is all that it needs to know. For 802.3 based MACs, the Prelude argument would contain the D-MAC and S-MAC addresses. For 802.11 MACs, the prelude would contain the 4 addresses plus the other assorted odd bits of an 802.11 frame. The extension to other MAC formats is trivial. thank you very much for your commentary Kevin Nolish -------------------------------------------------------------------------------- From: Mick Seaman [mailto:mickseaman@sbcglobal.net] Sent: Thursday, May 14, 2009 1:25 PM To: Kevin Nolish Subject: Fw: 802.1H Ballot Kevin, If it helps I can try to get this into the form of a comment, though I find the Excel spreadsheet frustrating when trying to put in such a long comment. Mick ----- Original Message ----- From: Mick Seaman To: Kevin Nolish Cc: Tony Jeffree ; Steve Haddock Sent: Wednesday, May 13, 2009 6:06 PM Subject: Re: 802.1H Ballot Kevin, Now that I have my head straight about what we are trying to do (essential to read my earlier message, immediately following, before attempting this one) I can see what types of service we are trying to support, and how the encoding and decoding works. Note particularly that the decoding/service recognition should be specified separately from the encoding - it's a mess lumping "forwarding behavoir" with frame fields/decoding. There are not three or more types of service at all, as should become apparent. Begin: There are two types of service we are trying to support above the MAC service, MAC Service plus one or other of: 1. EtherType protocol identification 2. LLC protocol identification [Most of the confusion has and continues to arise because an LLC encoding is sometimes used to encode EtherTypes, and when is not terribly obvious. Usual problem with people confusing *what* service is provided with *how* service is supported.] [Each and every frame uses one and only one of these two protocol identification methods (at its outer level, see latter for tag stacking) and the entire service can be expressed as comprising the MAC Internal Sublayer Service (ISS) as is plus one additional 'protocol identification type' parameter which can be "EtherType protocol identification", or "LLC protocol identification" (the EtherType is the first two bytes of the SDU following, the LLC protocol identification information includes the length and both LLC addresses, how this information gets carried around is a current weakness of applying the bridge specification to MACs of different types).] Encoding (Transmit): ENC 1. If the transmit request specifies EtherType protocol identification and the media supports Type/Length encoding use it (no LLC SNAP SAP). ENC 2. If the transmit request specifies EtherType protocol identification and the media does not support Type/Length encoding and the EtherType is not in the Selective Translation Table, encode the EtherType using SNAP SAP RFC 1042 (i.e. AA-AA-03-00-00-00 before the EtherType). ENC 3. If the transmit request specifies EtherType protocol identification and the media does not support Type/Length encoding and the EtherType *is* in the Selective Translation Table, encode the EtherType using BTE (SNAP SAP with BTE OUI, i.e. AA-AA-03-00-00-F8 before the EtherType). ENC 4. If the transmit request specifies LLC protocol identification, encode using LLC rules (put Length in Ethernet, followed by the data inc the LLC addresses see above). Decoding (Receive): DEC 1. If the received frame was encoded using the Type interpretation of the Type/Length field, then the corresponding receive indication specifies EtherType protocol identification. DEC 2. If the received frame was encoded using SNAP SAP RFC 1042 and the EtherType is not in the Selective Translation Table, then SNAP SAP header is removed and the corresponding receive indication specifies EtherType protocol identification. DEC 3. If the received frame was encoded using SNAP SAP RFC 1042 and the EtherType is in the Selective Translation Table, then the SNAP SAP header is removed and the Length prepended to the frame data and the corresponding receive indication specifies LLC protocol identification. DEC 4. If the received frame was encoded using BTE, then the corresponding receive indication specifies EtherType protocol identification. Tagging (adding a tag): TAG 1. If the frame to be tagged uses EtherType protocol identification, add the tag (EtherType, Tag Control Information) and set the protocol identification parameter associated with the frame for subsequent use in a transmit request or further tagging or detagging operation to "Ethertype protocol identification". TAG 2. If the frame to be tagged uses LLC protocol identification make sure that the Length field is included in or has been prepended to the frame data. If the Length field is too long (i.e. conflicts with EtherType allocations) drop the frame, otherwise add the tag (EtherType, Tag Control Information) exactly as for the case of TAG 1 above and set the protocol identification parameter to "Ethertype protocol identification". Detagging (removing a tag): DETAG1. If the frame to be detagged uses EtherType protocol identification, remove the tag (EtherType, TAG Control Information). DETAG2. If the frame to be detagged uses LLC protocol identification you implementation has made a mistake. Freak out. Note: The drop action is specified in TAG 2 because the subsequent frame would be ambiguous, and misinterpreted if it was ever detagged on Ethernet. The argument could be made that it would be safe if that could be prevented. In practice I think this is the long term killer for LLC protocol identification, it can't be used on long frames that might be tagged (possibly a few times) and eventually detagged on some remote Ethernet. End: The above rules can be used with the existing bridge specs to perform all the necessary translations. There is no real need to discuss pair-wise cases, and indeed not much need to talk about different media except so far as they affect (a) the choice between ENC1 and ENC2, and (b) where the Length field comes from. Substitute M_UNITDATA.request for "transmit request" and M_UNIDATA.indication for "receive indication" in certain contexts for impressive formality. Mick ----- Original Message ----- From: Mick Seaman To: Kevin Nolish Cc: Tony Jeffree ; Steve Haddock Sent: Wednesday, May 13, 2009 3:50 PM Subject: Re: 802.1H Ballot Kevin, I think the document is better than it was, but I'm afraid it still fills me with a sense of despair. I don't know how to make point comments that would get it where it needs to go. At present it seems very obscure (though no worse than it was before - I am not blaming you) and I have no idea what some one coming to it without participating in the original discussion on 802.1H would make of it. As I was reading it I too got hold of the entirely wrong end of the stick, and simply gave up trying to check for technical accuracy. I think I have a major point that may help get us out of the above situation. I'm copying Tony and Steve in case they might be able to help. We should really explain the problem that led to the introduction of BTE, and indeed to this whole document, and not hide it the way we had to do the first time to be allowed to get to do the work at all. Otherwise BTE looks completely miscellaneous and obscure. This point needs to be made very early on in the document. I think clause 1.2 is the correct place, the following is suggested text, whatever we do with it we should be at least sure that everyone thinks this is what is going on: "When the protocol discrimination standardized in IEEE Std 802.2 Logical Link Control (LLC) was developed, it was anticipated that the use of LLC Addresses would complete replace the use of EtherTypes with all IEEE 802 LAN Media Access Control methods (MACs), including with IEEE Std 802.3. Indeed the term EthernetTM (as opposed to IEEE Std 802.3) was held to refer to prior non-standard technology that would be completely replaced. LLC Addresses were indeed used, without reference to EtherTypes, with a number of new MACs including Token Ring (IEEE Std 802.5, now withdrawn) and FDDI (following many, but not all of the Token Ring design decisions). However it soon became apparent that there was a need to use protocols previously identified by EtherTypes on these new MACs. It was not practical to assign distinct new LLC Address values for each EtherType--there was no administrative apparatus in place to do so, there are far fewer LLC Addresses available for this purpose (2**7) than EtherTypes (2**16), and there were insufficient motivated resources available to modify existing implementations of protocol stacks. Against that background the SNAP SAP encapsulation was proposed in RFC 1042, and standardized in IEEE Std 802. By assigning the LLC Address 0xAA to identify a protocol whose sole purpose was to provide EtherType protocol discrimination on IEEE 802 MACs, a system could use a new MAC with existing implementations of one or more EtherType identified protocols simply by adding the octets string AA-AA-03-00-00-00 (hexadecimal) before the EtherType on transmission, and removing it on reception. This proposal raised the possibility of using SNAP SAP encapsulation to convey frames using EtherType protocol discrimination on IEEE Std 802.3 LANs, a media type not readily distinguishable from EthernetTM. In general, protocol implementations were not modified to conform to IEEE Std 802.2 by adding the SNAP SAP, and IEEE Std 802.3 has been subsequently modified to allow EtherType interpretation of the Type/Length field that follows the source MAC address. Unfortunately at least one proprietary protocol in widespread use adopted the SNAP SAP format on Ethernet, but also used the difference between the 'native' EtherType format and the SNAP SAP format to distinguish two revisions of the protocol. A problem therefore arose when frames for these protocols were bridged from Ethernet to FDDI and back to Ethernet. Each bridge naturally added the SNAP SAP tag to 'native' EtherType identified frames, for transmission on FDDI, and recognised and removed the SNAP SAP tag from FDDI frames, prior to transmission on Ethernet. The distinction between frames originally transmitted using the IEEE Std 802.3 Type/Length field to convey the EtherType and those originally transmitted using the SNAP SAP tag had been lost. The purpose of this Recommended Practice is to: a) ensure that the potential for protocol identification translation problems between different 802 MAC types is widely known; b) discourage any further use of the difference between the Type/Length field encoding and the SNAP SAP encoding of a single EtherType to distinguish between protocols; c) ensure that any given protocol is represented by only one protocol identification format on IEEE Std 802.3 LANs, so avoiding the need for recipients of frames for that protocol to recognise a number of different formats; d) provide for interoperability between bridges that bridges from one MAC type to another, including interoperability for protocols that attempted to use the Type/Length and SNAP encodings to distinguish different protocols. This statement of purpose is usefully augmented by the intent to minimize further disruption and difficulties in deployment and use of 802 MACs. The use of the SNAP SAP (with the RFC 1042 value of 00-00-00 in place of an OUI) has been retained as the favoured way of identifying frames using EtherType protocol identification for 802 MACs that do not explicitly provide another way to identify such frames, and do use LLC. The use of the Type/Length field is retained on IEEE 802.3 LANs. An EtherType protocol identified frame that is bridged along a path that includes an FDDI LAN (for example) will therefore arrive at an Ethernet attached station with the Type/Length field encoding of the EtherType. A frame that is intended to have the SNAP SAP RFC 1042 encoding on Ethernet can be bridged on such a path provided that its associated EtherType appears in a Selective Translation Table, used by each Bridge Port attached to an IEEE 802.3 LAN. A single EtherType is recommended for inclusion in this table, and the purpose of this standard includes minimizing the chance that any further entries will be required. If an EtherType appears in the Selective Translation Table used by each Bridge Port, a frame that is originally transmitted using the Type/Length field encoding of that EtherType is transmitted on FDDI (for example) using the SNAP SAP with an OUI value of 00-00-F8 before the EtherType. This encoding is referred to as the Bridge Tunnel Encapsulation protocol and identifies a frame that should always be transmitted on an 802.3 LAN using the Type/Length encoding of EtherType, irrespective of the inclusion of that EtherType in the Selective Translation Table. It should not be used directly by end stations attached to any type of LAN. Bridges and end-stations can use EtherTypes to identify tags, such as the Customer VLAN TAG (C-TAG) specified by IEEE Std 802.1Q or the SecTAG specified by IEEE Std 802.1AE, than can be added to a frame after the source MAC address and before the LLC Addresses or an EtherType. When a frame is bridged from one media type to another the only protocol identifiers that are candidates for translation are those that immediately follow the source MAC address at one or more of the Bridge Ports through which the frame is relayed. The bridge components that perform the relay function are generally unaware of the presence (or absence) of further tags in the frame and do not translate them (some tags can serve to mark a point in the frame where the original data is not available to the relaying bridge, e.g. identifying the use of encryption in the case of the SecTAG). Since tags can be removed or added when relaying between like as well as dissimilar MACs, it is important that all tags and other protocol identfiers in the frame other than the very first are in media independent form. The addition of a C-TAG, for example, means that a SNAP SAP RFC 1042 encoded EtherType has to be re-encoded in Type/Length format (i.e. without a preceding AA-AA-03-00-00-00 octet string even if the frame is transmitted on FDDI. This purpose of this Recommended Practice has therefore been extended by the revision to: e) ensure that the requirements for protocol identification translation of tags when adding or removing tags on media that do not support Type/Length field encoding of EtherTypes are well-known. " Well that's a hell of a Purpose clause (its taken me about 4 hours to write), but I think that it or something like it is necessary, at least within Clause 1. Actually from my point of view you could adopt this purpose and toss the rest of the document, but some people will want to see all the formats etc. Mick ----- Original Message ----- From: Kevin Nolish To: mickseaman@sbcglobal.net Sent: Tuesday, May 12, 2009 10:35 AM Subject: 802.1H Ballot Hi Mick, I have a favor to ask. I understand that you are pressed for time and an abstain lack of time on 802.1H is just fine. If you can find the time I'd appreciate it if you could do a short sanity check on the document just to make sure it's progressing along the lines you thought proper. I'm not asking for a full commentary and review, just a short check with a "thumbs up" or "thumbs down" on the overall direction. thanks, Kevin Nolish