Date: 10 Jun 96 12:19:45 EDT From: Tony Jeffree <100271.522@CompuServe.COM> To: 802-1 Subject: 802.1D re-affirmation ballot comments from 802.5 The attached has been forwarded to me by Trevor Warwick regarding 802.1D reaffirmation. Regards, Tony ---------- Forwarded Message ---------- From: "Trevor Warwick INF-SP", INTERNET:twarwick@madge.com TO: Tony Jeffree, 100271,522 CC: (unknown), INTERNET:STDS-802-5@MAIL.IEEE.ORG Bill Lidinsky, INTERNET:LIDINSKY@HEP.NET DATE: 10/06/96 06:37 RE: 802.1D re-affirmation ballot comments from 802.5 Date: Mon, 10 Jun 96 11:33:15 +0100 From: "Trevor Warwick INF-SP" Organization: Madge Networks To: 100271.522@compuserve.com (Tony Jeffree) Cc: stds-802-5@mail.ieee.org, lidinsky@hep.net Subject: 802.1D re-affirmation ballot comments from 802.5 Tony, Here are two comments on the 802.1D/D11 re-affirmation document, submitted by 802.5, as a result of discussions at our recent Interim meeting in Santa Clara. As none of the regular 802.5 members have votes in 802.1, we will also be sending this as a formal submission to 802.1 from 802.5 at the Plenary in July. -- Trevor Warwick email : twarwick@madge.com Madge Networks, voice : +44 (0)1753 661401 Sefton Park, Bells Hill, fax : +44 (0)1753 661011 Slough, England. ============================================================================= Comment 1 ========= While reviewing the 8802-5:1995 standard and working on the 802.5r DTR draft standard, the 802.5 working group noticed a mismatch between the behaviour required by the Source Route Bridging Annex of ISO 10038, and the required 802.5 MAC behaviour. As background, remember two key points about 802.5. It has traditionally used source route bridging, and the MAC definition requires a station to receive (MA_UNITDATA.indication) its own transmitted frames (MA_UNITDATA.request) if there is a DA match. The mismatch is as follows: In 10038 section C2.5.1, there is a difference in behaviour between reception of a source-routed frame that was transmitted by the receiving MAC, and reception of a non-source-routed (i.e. transparent) frame that was transmitted by the receiving MAC. According to C2.5.1, reception of a transparent frame does not cause the generation of an M_UNITDATA.indication primitive. This is to avoid sending a frame that originated from the Bridge Relay function back into the Bridge Relay function. However, reception of a source-routed frame does cause an M_UNITDATA.indication if there is a source-routing match for a specifically routed frame, or if the frame is an SR explorer. This is needed for support of full source-routed connectivity to the bridge port's local LLC. One problem is that this does not match the actions in the state tables in 8802-5:1995, which define the operation of the 802.5 MAC. Transition 37 states that on receipt of *any* frame, an M_UNITDATA.indication is given. Another problem is that source-route matching is defined to be a function of Bridging, and not of the MAC layer. The existing description in 10038 implies that the MAC layer does the source-route matching. Proposed solution ----------------- Both problems will be addressed by modifying each document to make them consistent with each other. The proposed changes to 10038 remove the incorrect requirement on the MAC to do source route matching. The proposed changes to 8802-5 add extra transitions to the MAC state tables to show the correct action with respect to Bridge Relay on receiving frames with the RII bit on or off. Detailed changes to 10038 (references are to Draft 11 PDF file) --------------------------------------------------------------- In section C2.5.1, remove the following piece of text starting at line 9, which removes the implication that the MAC entity does source-route matching. " and with the constraint that either a) The routing type indicates a specifically routed frame and the LAN-in ID-Bridge Number-LAN-out ID sequence matches a unique port-to-port sequence designated to the Bridge; or b) The routing type indicates All Routes Explorer or Spanning Tree Explorer frame" Informational - Changes to 8802-5 --------------------------------- Exact changes to be determined by 802.5S editor, but intent is as follows. Split Transition 37 into two cases: Transition "37a" to cause M_UNITDATA.indication if any frame is received with RII=1. Architecturally, any non-matched frames will be discarded by the SRT Bridge Relay. Transition "37b" to cause M_UNITDATA.indication only if a frame is received with RII=0, and the station is in Transmit State TS=RPT. Comment 2 ========= There is another issue with the current version of 10038, which is that it doesn't support Dedicated Token Ring MACs (for the case of a traditional SRT bridge that has a DTR-capable MAC). Is it appropriate to modify 10038 now to support 802.5r, which is almost complete ? On a quick search of 10038, just removing the detailed references to token-based transmission may be sufficient. In section C2.5.1, modify the sentence on page 177 line 4, which is overly specific about the frame transmission method: "The frame is enqueued for transmission on reception of a suitable token" to "The frame is enqueued for transmission". The same comment applies in 2.5.3 on page 41 line 44, but the reference needs removing as well. Other places that would need changing, to mention 802.5r in addition to 8802-5, are: 2.5.3, page 41 lines 39 and 40. C2.5.1 page 176 lines 50 and 51.