Date: 22 Jun 95 06:39:29 EDT From: Tony Jeffree <100271.522@compuserve.com> To: "802-1 <"< Subject: Input paper for July meeting The attached is an input paper for the July 802.1 meeting, related to the proposed PAR for traffic class expediting & dynamic multicast filtering in bridges. The Email copy of the text omits a diagram; a paper copy of the document will be made available at the meeting. Regards, Tony. ******************************************************************* TITLE: Proposed Changes to 802.1D Section 3 SOURCE: Tony Jeffree/Mick Seaman/Peter Wang DATE: 22 June 1995 Preamble: This document drafts an initial proposal for the set of changes required in 802.1D Section 3 in order to incorporate the concepts of traffic classes and multiple queues, as required for the operation of traffic class expediting/dynamic multicast filtering in bridges. The document is organized as a set of editing instructions, with proposed replacement text & diagrams as appropriate. Editing instructions and editors notes are distinguished from replacement text by their being enclosed within parentheses, thusly: [Editing instruction/Editors note] Replacement text -------------------------------------------------------------- [Section 3.1.1 Relay] [Renumber existing bullets 6 through 10 as bullets 7, 9, 11, 12 and 13 respectively. Add the following bullets in appropriate sequence:] (6) Selection of traffic class, following the application of filtering information. (8) Queuing of frames by traffic class. (10) Selection of queued frames for transmission. [Note: Frame discard and outbound priority selection are based on traffic class; this is discussed in the proposed changes to 3.7, Frame Forwarding.] [Section 3.1.2 Filtering Information] [Extend scope of discussion on spanning tree filtering/preservation, traffic reduction, traffic expediting to include traffic classes. Restructure/replace 3.1.2 under new title, as follows:] 3.1.2 Filtering and Relaying Information A Bridge filters frames, i.e., does not relay frames received by a Bridge Port to other Ports on that Bridge, in order to prevent the duplication of frames (2.3.4). The function that supports the use and maintenance of information for this purpose is: (1) Calculation and configuration of Bridged local Area Network topology. A Bridge filters frames in order to reduce traffic in parts of the Bridged Local Area Network that do not lie in the path between the source and destination of that traffic. The functions that support the use and maintenance of information for this purpose are: (2) Permanent configuration of reserved addresses. (3) Explicit configuration of static filtering information. (4) Automatic learning of dynamic filtering information through observation of Bridged Local Area Network traffic. (5) Ageing out of dynamic filtering information learned through observation of Bridged Local Area Network traffic. A Bridge classifies frames into traffic classes in order to expedite transmission of frames generated by critical or time-sensitive services. The function that supports the use and maintenance of information for this purpose is: (6) Explicit configuration of traffic class information in the Filtering Database. [Should this information be regarded as part of the Filtering DB, or as Port state information?] [Figure 3-1 gives an example Bridged LAN configuration which is an illustration of the simple combinations of dual port/multiport bridges, redundant paths, Etc. It is likely that some more representative target topologies will get included as an appendix in the future. Dont want to include these in the main body of section 3 because it will need a tutorial, which will cloud the main discussion.] [Section 3.3 Model of Operation] [Insert the following text as the (new) first paragraph of 3.3:] The model of operation is intended simply as a basis for describing the functionality of the MAC Bridge. The model as described is in no way intended to constrain real implementations of a MAC Bridge; such real implementations may adopt any internal model of operation that is compatible with the externally visible behaviour that this standard specifies. Conformance of equipment to this standard is defined purely in respect of observable protocol. [Re-draft bullet (3) to allow for traffic class queries on the Filtering Database, as follows:] (3) The Filtering Database (3.9), which holds filtering information either explicitly configured by management action or automatically entered by the Learning Process, and which supports queries by the Forwarding Process: (a) as to whether frames with given values of the destination MAC address field should be forwarded to a given Port, and (b) to determine the traffic class to be assigned to a given frame. [In Fig 3-4, re-name the box currently marked "Frame Forwarding" as "Forwarding Proces".] [Section 3.7 Frame Forwarding] [Replace Section 3.7 and its subsections, and insert new diagram, Fig. 3-7, as follows:] 3.7 The Forwarding Process Frames transmitted to the Forwarding Process by the individual MAC entity associated with each port (3.5) shall be forwarded to the other Bridge Ports subject to the discard, queuing and mapping functions of the Forwarding Process. These functions enforce topology restrictions (3.7.1), use filtering database information to filter frames (3.7.2) and regenerate user_priority (3.7.3), queue frames (3.7.4), select queued frames for transmission (3.7.5), map priorities (3.7.6), and recalculate FCS if required (3.7.7). These functions are described in terms of the action taken for each of the potential transmission ports for a given received frame and reception port. Figure 3-4 illustrates the operation of the Forwarding Process in a single instance of frame relay between the Ports of a Bridge with two Ports. Figure 3-7 illustrates the detailed operation of the Forwarding Process. [Produce "C" Code at the end of 3.7 to describe Forwarding Process, with appropriate discussions. I guess this can wait until the text/principles of operation are fixed.]