MINUTES OF IEEE 802.3Z GIGABIT TASK FORCE Coeur d'Alene, Idaho September 9-11, 1996 DAY ONE [The computer file for the first day was lost, so the minutes for Day One contain presentation summaries only. Recording secretary apologies for any inconvenience.] 1. WELCOME AND INTRODUCTIONS Meeting was convened around 8:40 a.m. by Howard Frazier. All attendees introduced themselves and affiliations. HF (Howard Frazier) proposed the following agenda: 1. Welcome and Introductions 2. Select Recording Secretary 3. P802.3z Status Report 4. Email Reflector and Web/FTP Site 5. Standards Developement Timeline 6. Review HSSG Objectives 7. Technical Presentations 8. AOB 9. Plans For Next Meeting 10. Approve Minutes of July Meeting 11. Adjourn 2. SELECT RECORDING SECRETARY Steve Dreyer scratched his head at the wrong time and was inadvertently volunteered to take minutes. 3. P802.3z STATUS REPORT HF gave brief history of P802.3z (see HF presentation at FTP site). HF summarized voting rules that were established at previous meetings: All present at time of vote may do so if they feel qualified (pretty exclusive), >50% needed to pass procedural motions, >=75% needed to pass technical motions. 4. EMAIL REFLECTOR AND WEB/FTP SITE HF went over procedures for using the email reflector and Web/FTP site (see HF presentation at FTP site). The email reflector is at: stds-802-3-hssg@mail.ieee.org The Web/FTP site is at: ftp://stdsbbs.ieee.org/pub/802_main/802.3/gigabit 5. STANDARDS DEVELOPEMENT TIMELINE HF showed the development timeline for the already approved 100 Mbps standard, and then showed a proposed development timeline for 1Gbps standard needed to produce an approved standard by 1998. To meet the 1998 approval date, the 1Gbps standard has to have a technical proposal cutoff date in Nov., 1996, a first draft in Jan., 1997, first ballot (working group ballot) in July, 1997, and final ballot (LMSC ballot) in Nov., 1997. Some discussion about about the agressiveness of this schedule, but general agreement on the necessity of meeting it. 6. REVIEW HSSG OBJECTIVES HF went over the already established fifteen objectives for P802.3z (see HF presentation at FTP site). 7. TECHNICAL PRESENTATION Architecture and Organization of Standard - Howie Johnson This presentation described the specific layers proposed for 1Gbps and how a standard could be written to specify these layers. The function of each layer and how each layer will map into the 7 layer OSI Reference Layer Model was described. The 1Gbps layers were contrasted against the existing 10 and 100 Mbps layers. Detailed blocks within the proposed PCS, PMA, and PMD layers for 8B10B operation were described. Finally, the presentation proposed how the 1Gbps standard could be incorporated into existing IEEE 802.3 standard by the addition of eight new chapters and the modification of five existing ones. A User's View of Gigabit Ethernet - Bob Fink This presentation traced the development of the intracompany network at Lawrence Berkely National Laboratory from 1983 to the present. The grouth of workstations in that period was from 0 to >8000 stations. The bandwidth of typical workstation was 20-25 Mbps a year ago, but now it has increased to 120-200 Mbps. Not enough bandwidth and shared media congestion are the source of most of their network problems now. Thus, the LBNL network is quickly migrating to LAN switching, full duplex, and Fast Ethernet. 1Gbps Full Duplex Ethernet is probably the easiest and most desirable way to solve their future network needs. Review and Update of Carrier Extension Proposal - Howard Frazier This presentation outlined the carrier extension proposal for CSMA/CD. Some common topologies that might be used for 1Gbps Ethernet were shown, and it was concluded that there is not enough bit budget margin for CSMA/CS operation, with or without the cable delays. This bit budget problem can be solved by the carrier extension mechanism: extending the size of frames less than 512 bytes to 512 bytes by inserting non data symbols at the end of the normal data, and using these non data symbols to extend the carrier sense in a receive station. Changes to the MAC Pascal code to add carrier extension were described. Tables and a graph of simulated performance of a CSMA/CS network using carrier extension was shown. CSMA/CD Bit Budget - Stephen Haddock This presentation summarized the current bit budget calculations for CSMA/CD operation. A worst case bit budget model for collision was shown. Assumptions on bit delays for each block were then described. Bit budget calculations were then shown for DTE and Repeater, and total bit delays for Fiber and UTP were calculated. Conclusion was that bit budget is too high, and it was shown that extending carrier to 512 bytes will allow CSMA/CD operation on a 200 meter diameter network of either Fiber or UTP. 1000Base-X Repeater Gigabuffer-Lite - Mark Feurstraeter This presentation outlined a new proposal for a 1Gbps CSMA/CD repeater, termed Gigabuffer Lite. A brief history of repeaters was give, and summary of other repeater topologies was shown. The Gigabuffer Lite proposal was then described, which is one that uses local storage of data on each receive channel, an acknowledge signal from the repeater core to accept that locally stored data and retransmit it to the other ports, and an arbitration scheme to handle multiple data requests. The Gigabuffer Lite proposal was contrasted in a table to other proposed repeater and CSMA/CD schemes. 802.3z CSMA/VCD Proposal - Moti Weizman This presentation described a new proposal for 1Gbps CSMA/CD operation, termed Virtual Collision. A set of goals was presented for a 1 Gbps repeater. The Virtual Collision concept was then described as combining the use of virtual collisions (hub broadcasts first frame and discards other frames that collide, DTE always transmits after 1 slot time and retries after 0 slot times) with carrier extension (to 256 bytes) and frame batch (more than one frame within a packet). Changes to the standard to implement Virtual Collision was described. A graph comparing Virtual Collision to carrier extension only was shown. Gigabuffer Repeater Proposal - Bernard Daines This presentation proposed a new repeater structure for 1Gbps Ethernet, termed Gigabuffer. The history of CSMA/CD from the beginning until now was presented. A need for a repeater topology that had better performance than carrier extension and lower cost than switches was presented. The Gigabuffer proposal was then described as a way to meet these goals by using a MAC, local storage, and flow control to convert full duplex signals on the link to half duplex signals inside the repeater core. Year 2000 CSMA/CD Choices - Bernard Daines This presentation proposed CSMA/CD in a box as the best choice for CSMA/CD for next generation networks. The different methods proposed for CSMA/CD were generally described. The paramters that dictate good CSMA/CD performance in both 1996 and 2000 were offered. The CSMA/CD in a Box proposal (a.k.a Gigabuffer) was offered as the best choice for CSMA/CD for now and in the future. Gigabit CSMA/CD, Calling for a Resolution - Gideon Prat This presentation urged all parties within the 802.3z to reach a resolution on how to do 1Gbps Ethernet so it can become a reality now. A view of ideal 1Gbps goals was presented. The various proposals offered to date were reviewed and compared against these ideal goals. A case to reduce the link length to 50m was made. Finally, the presentation called on everyone to reach a resolution on 1Gbps Ethernet in order to meet market timeframe needs. Flow Control for Gigabit Ethernet - Gideon Prat This presentation proposed a credit based flow control scheme. Flow control needs for both 100 Mbps Ethernet and Gigabit Ethernet were contrasted. The limitations of a XON/XOFF flow control scheme for Gigabit were described in detail. A new credit based flow control scheme was outlined. Gate counts for 802.3x and new credit based flow control scheme were presented. Presentator offered to do more work if others are interested. Proposal to Enlarge Frame Sizes for Gigabit Ethernets - Sajit Bhaskaran This presentation proposed an increase in the maximum Ethernet frame size. Reasons to increase frame size were described. Some application examples where existing max frame size causes problems were explored. Proposal to enlarge max frame size to 32K bytes was offered. Gigabit MII (GMII) Issues and Recommendations - Robert Grow This presentation outlined the details of the proposed electrical interface between the PCS and PMA blocks, termed the GMII. The transmit and receive GMII signals and their associated functions were described. The transmit and receive encoding tables were presented. MII for Gigabit Ethernet - Jacob Twersky This presentation also described the details a proposed electrical interface between the PHY and MAC, termed the Gigabit MII. The objectives and justification for an interface between the MAC and PHY were presented. The MII signals for 100 Mbps were reviewed. New signals for Gigabit MII were then proposed. Transmit and receive signal encoding tables were described. Finally, timing diagrams and some simulation data were presented. HF adjourned meeting at around 5:45 p.m. DAY TWO HF brought meeting to order at 8:40 a.m. Technical presentations continued. Update To PCS Protocol Proposal - Howie Johnson This presentation described the PCS layer for 8B10B in detail. A block diagram showing the PCS layer in relation to other layers along with all the current interfaces was shown. The link startup protocol along with link configuration algorithm was described. Proposals for the definition and usage of the EOP and SOP delimiters was then presented. Finally, a proposal for the idle symbols was shown. Gadi: Don't you need a state from LINK_ACK to top if no ACK is received from far end? Howie: Yes Gadi: Do we really need to have the R after the T in the EOP? Howie: TR both needed for error robustness. One error could prematurely end the packet and the packet could still theoretically pass the CRC test, which is a no no. John Doe: Why do we need two R's if the packet ends on even boundaries? Howie: Error robustness, two errors could move the end of packet indication falsely. There is a proof of robustness presentation on the IEEE email reflector. John Doe: Why not have two different R's instead of two different I's to fix dispariyt? Howie: There is a limited number of codes to pick, and most of them are DC balanced, and T and R are both DC balanced, thus they cannot affect disaparity. Howie: There are two different idles to fix disaprity, once it is fixed, all subsequent idles will not fix disparity. HF: It seems that there needs to be a 3 octet pipeline to sense the TRR delimiters in the EOP. So is there a three octect delay in the PCS? Howie: Yes HF: This three octect delay must be accounted for in bit budget. Steve H: This has been accounted for in my bit budget presentation, even though it is not illustrated in block diagram. Bill Q.: It seems that the first idles after the EOP are needed to fix disparity. Howie: Thats how it is intended to work. Gigabit Ethernet Serial Link Codes - Rich Taborek Gigabit Ethernet Serial Link Codes, Change Summary Rev. 4 - Rich Taborek The first presentation is a proposal for usage of 8B10B codes in the PCS layer. The second presentation summarizes the differences between the presentor's Netherland's handout (Rev. 3) and the current presentation (Rev. 4). The presentation started with a detailed definition of terms and assumptions. Then, a description for each ordered set was described. The link configuration algorithm was outlined. The 8B10B coding table was discussed. An example of a packet was examined. Synchronization algorithms were discussed. HF: Packet Packing was never voted in formally, so it does not need to be accomodated in your Example on Pge 4. Rich T.: OK Shimon: In Configuration register, do we need a flow control register bit? Rich T.: It has never been discussed,,,,, HF: Full duplex spec requires flow control bit, so we may have to put it in John Doe: What does receive synchronization mean? Rich T.: It means synchronizaiton done, alignment done, link up Gideon: VLAN proposal has addition of 4 bytes to max packet size. It is this OK? Rich T.: Seems that 4 extra bytes will not affect this proposal Howie: Seems to not affect MAC, but may affect PCS (lost answer) Gideon: It would be good to have more bits in Configuration register for flow control for future use. Rich T.: We are trying to follow Clause 28 definition, the next page function will allow future expansion. Howie: (showed slide of config. Register and showed lots of extra bits available) John Doe: Is a TRS code as robust as the TRI codes? Rich T.: Yes Mike S: Future UTP proposals may want to use short haul and long haul bit. Rich T.: Maybe Transparent Signalling Channel - Igor Zhovnirovsky This presentation is an overview of a proposed new signalling channel, termed the TSC. TSC was described as a way to send control and signalling information during the idle period between packets. The benefits and costs of TSC were presented. The format of the proposed TSC was shown. The algorithm to exchange data between two stations using TSC was pictorially described. John Doe: If only one TSC is allowed in a IPG, there is not truncation problems Igor Z: This is true, but multiple TSC's are sometimes needed, so it is useful to send more than one TSC in a given IPG. John Doe: But bandwidth is low, so if you need more bw use inband signalling Igor Z: True, can be modified. John Doe: Does TSC alter disparity between packets? Igor Z: It should not affect disparity Moshe: If only one TSC is allowed, flow control functions will be adversely affected Igor Z: True Dave L. Will TSC pass thru repeaters OK Igor Z: TSC functions below MAC and does not affect repeater functionality. Dave L: Does TSC impact bit budget numbers? Igor Z: Don't know John Doe: I am worried about about this affecting error robustness, and I believe all applications could use the autonegotiation function (configuration register). Igor Z: Autonegotiation is only done at link startup, and things later can not be addressed John Doe: But autonegotiation can be redone at any time Igor Z: Possible, but link has to go down, very tedious. Gideon: This is a PHY based out of band signalling protocol. So you need to have some management layer below the MAC which doesn't exist now and may be burdensome. Igor Z: Our group believes that these problems are easy to solve if sufficient interest Shimon: Why not do this in the preamble instead of in IPG? Igor Z: Possible, our group thought IPG way was easiest. Rich T.: Link startup affects both end of link and MAC, TSC does not affect MAC. This is difference between the two. John M. What does the bit set in the configuration register mean? Igor Z: Bit set means that the MAC supports the TSC function. John Doe: One of the advertised benefits is to provide expansion of multi-gig speed? What does this mean. Mike S: (didn't understand answer) Pat T: How come the TSC doesn;t change the running disparity, expecially when it is truncated? Rich T: Everything is being funneled to PCS block which makes the the disparity decisions. Physical Coding Sublayer (PCS) and the Transparent Signalling Channel (TSC) - Alak Deb This presentation described the architecture of the TSC in detail. A block diagram of how the TSC would fit into the existing proposed Gigabit PCS and MAC layers was shown. Descriptions of each of the layers was presented, and a list of messages needd between the PCS and MAC to implement TSC was presented. John Doe: Why is MAC have to involved in TSC Alek: IPG may need to be variable. John Doe: Any study on reliability and robustness? Alek: Nothing has been done yet, it is protocol dependent. John Doe: Why not use 802.3 MAC control frames for transparent signalling? Alek: Possible, but TSC is designed to be transparent to MAC frames and TSC is intended for small amounts of data, simple stuff. Transparent Signalling Channel (TSC) Applications - Alak Deb This presentation gave an overview of two possible applications for TSC: IPG management for memory optimization, and dynamic channel indexing to a CAM for easier routing table identification. Gadi: Is this like VLAN tagging? Alek: Yes, the preamble is like VLAN tagging, but this is usd for CAM filering, has nothing to do with VLAN. Alek: When the DTE sends a packet, the address has to be checked against the routing table, and this can be used for that. Shimon: IPG management needs to be standardized to work. Do you plan to change the standard? Alek: No, users don't have to have this function. Shimon: How can you autonegotiate IPG? Doesn't Alek: If you can design switch for minimum IPG, then you don;t even have to support this function. Slow Clock Distribution - Igor Zhovnirovsky This presentation described another possible application for TSC: clock distribution. The distribution requirements for 8KHz sample clock in a WAN network was described. A scheme for distribution of the 8KHz clock from in a WAN with an Ethernet LAN using TSC was presented. John Doe: How is it possible to subordinate the clock distribution funciton to data traffic? Igor Z: When MAC sends transmit command, the PCS has a block with speeds up or slows down the clock the required amount. John Doe: What is the info that needs to be distributed and how often? Igor Z: In this example, the info is a time reference for the entire network (8KHZ clock source). In this example, needs to be updated every 125 uS. Geoff: In extended network with multiple clock references, how do you resolve this? How can this be standardized? Igor Z: This example is for a limited number of nodes, and what we are proposing to standardize is the ability to send small amounts of signalling data, not the actual clock distribution scheme. John Doe: In this application, it would be cheaper to have a WWV receiver as a clock source on each port. John Doe: If there is different vendors on each side of the link, then how can this scheme be interoperable? Igor Z: There are some interoperability issues, but that doesn't prevent standardizing the TSC concept. Moshe: If you are not going to standardize any applications, how can they interoperate? Igor Z: This is the short answer. This is the first presentation on TSC. The goal is to look at applications to see if there is interest in futher work. There is more work needed, obviously. The point is to not hold back the standard for these applicaitons questions, so we propose to standardize the TSC proposal in order to allow the development of these applications in the future without affecting the schedule of the standard. John Doe: In fibre channel, an error occured if an ordered set starts out with a disparity error. Is this going to be a problem here? Rich T.: The PCS decides disparity, not the MAC. So the PCS takes care of this problem because it flips or not flips the disparity. John Doe: Is this true for idle as well? Rich T.: Still uncertain. If we use two idles, then no problem. If we have only one idle, we will have to have some more disparity rules. Mike S.: As one of the originators of the TSC proposal, the applications presented are not the only ones, others are possible. We have examined using the configuration approach and think SC is better. The TSC aproach doesn't affect the existing data in the MAC, it is fairly easy to implement, and doens't affect disparity. Bob G: First, there is a potential problem with disparity in repeaters with the TSC proposal. Second, we are builfing a structure for chaos. If there is a specific protocol to be standardized, then it mahy be a good thing. But if the protocol is not standardized and left up to each vendor, then there will be chaos and interoperability problems. If the OUI is used to identify vendor applications, this is still complex and undefined and prone to interoperabiltiy problems. Igor Z: I will respond to multiple comments. The protocol issue can be standardized and determined in the future. It doesn't have to be standardized now. The TSC proposal does in order to have the capability to do it in the future. John Doe: What is the point of clock distribution if you cannot go to end to end at gigabit speed? Igor Z: It can be used in gigabit Ethernet, but cannot be used on older Ethernet. Test/Maintenance/Offline Mode Proposal - Rich Taborek This presentation proposed adding a new offline mode. The offline mode would be enabled with a bit in the link configuration register. Some possible uses of the offline mode were described. State machines for link startup, power on, and diagnostic testing using the offline mode were presented. Mike S: Procedures for on and off need to set a limit on the number of F's sent and detected. Rich T.: Yes, I propose to send at least 8 F's to bring the link down before C's to reconfigure the link are sent. JT: How do you get back to diagnostic from restart Rich T.: (Answer not heard) JT: Does this override anything happing in the MAC layer? Rich T.: Yes, MAC is overriden JT: On Power On Procedure in Slide 6, why can't Port A send C's immediately after the first F? Rich T.: Port B needs to see a minimum number of F's John Doe: Is ther an opcode field going to be included to tell what diagnostic is running? Rich T.: Fibre channel doesn/t do this because diagnostic test tends to be isolated to the port being testing and doesn't affect other side. But it is possible to do it with next page. John Doe: Is the purpose of offline bit to signal the other end that you are going to do some diagnostic? Rich T.: Yes, you are teeling the other end that the link is not going down, just offline, and wait until it sees configuration before doing anything else. HF: In examples shown, only one side needs to act to enable offline command, is this true? Rich T.: Yes HF: If only one end is going to act, then Don't you need an ACK form both sides? Rich T.: My intention is that the idle symbol I is the handshake for the the ACK, probably need to write up a more specific descritption. PCS Priority Flag And VLAN Tags - Paul Congdon This presentation proposed a scheme for adding a priority flag to a packet. The proposed scheme placed a special symbol in the preamble to designate that that packet had priority. The effect of the priority flag on other Gigabit layers was discussed. This priority flag scheme was compared to the current 802.1 VLAN tagging proposal. Reasons that the priority flag scheme is a good short term solution for Gigabit priority was presented. Gideon: Are you proposing to use different schemes for 100 mb vs 1GB? Paul G: No, only one tag is proposed for 1Gb, other prototcols would not see tag. Gideon: Who is going to determine what the actual priority of a tagged packet is? Paul G: That is a management function done at higher layers. John Doe: If VLAN tag is also present, would the value of PRI be ignored? Paul G: The VLAN tag could also be put in the preamble, but this is currently undefined. John Doe: VLAN ID still may require a VLAN packet, so what is the benefit of the PRI tag? Paul G: The benefit is that for simple priority, the PRI scheme doesn;t require reformatting the packet, so for this funciton PRI is easier. (Some more discussion about differences between VLAN packets and PRI scheme) Gideon: 802.1q decided that managment will determine VALN tag, and there is already a draft for the VLAN packet already being circulated, and priority is already defined in this draft, so it seems that this defeats that proposal. Paul G: 802.1q decided to put priority in the VLAN tag, but it didn't disallow other schemes. The PRI scheme performs the same function and can be managed in the same way as a VLAN priority tag would. Gideon: This scheme may good because it can determine prioroity fast, but since it is not compatible with 802.1q poses problems. Paul G: The priority scheme can be standardized today with PRI, the other issues need further resolution in 802.1q. Milan: You are assuming the gigabit can determine the priority of a packet, then it can handle priority without the PRI scheme. Paul G: True, but PRI can work with 100 Mb and other protocols. Geoff: It seems that if this was adopted, then when VLAN tags are standardized, then we would have to have two ways to deal with priority which is undesireable. Also, the simplicity if this scheme is overshadowed by the management overhead needed to manage priority. Paul G: The two schemes can coexist. A VLAN tagged packet would override the PRI. For packets that do not have VLAN tag, then it works fine. John Doe: Are you proposing to add another bit in the configuration register? Paul G: No, you would look at the PRI byte to see if a priority is there. Steve H: This is solving the same problem the 802.1 group is trying to solve, and two solutions are undesirable to solve the same problem. Paul G: Both schemes are compatible and can interoperate together and do not conflict, thus both schemes can be accomodated. Copper PHY Evaluation Criteria - Sailesh Rao This presentation proposed a series of criteria that should be used to evaluate copper PHY proposals. The objectives for such a criteria set was presented. Each of the elements of the proposed criteria were then discussed in some detail. AA: On the EMI susceptibilty reuirements, do you need to operate while noise disturbance is still there? It seems that some level of functionality is there. Sailesh: Ron Crane's opinion is that it didn't have to work during noise, only recover AA: What about uncorrelated noise? Sailesh: That is covered by Ron Crane's test Pat T: A sine wave for EMI susceptibilty as a source is not representative of noise in real life, so some considerations has to be made to operate with impulse noise. Sailesh: We are proposing that the receiver never be shutoff during the noise distrubance, so the receiver would not be affected by the noise. Pat T: Turning off a receiver during noise distrurbance, that still may not keep receiver in "normal" state. Sailesh: Maybe true, do you have some representative noise disturbances that we can look at? NEXT Loss Models for Category 5 Links - Bob Campbell This presentation showed some meaured NEXT curves for UTP Category 5 wire. The setup used for the measurements was described in detail. Curves for two cable lengths and two connector types was presented. Mike S: Could you explain the differences between Sailesh NEXT model and your NEXT model? John Doe: Has Lucent ever tried to develop a model for cable systems? Seems that a model would be the answer . Bob C: Models have never approached real life measurements, so Lucent uses real life measurements. John Doe: Why wasn't the frquency extended beyond 100 MHZ? BC: Category 5 is only defined and spec'ed to 100 MHz. Sailesh: The IBM Ungerbok models are available. John Doe: How do models change with temperature? Bob C: These measurements were done at room temperature. Some more margin needs to be added for temperature. There needs to be decisions as to how to develop realistic worst case models. Mike S: Do your curves correlate to stuff deployed in real life? Bob C: My opinion is that there is at least 3db margin. John Doe: There is plenum and non plenum Cat 5 cable. Which one is this? Bob C: 1061 is a non plenum cable, but curves will hold for plenum cable at 20 C. John Doe: Are your measurements worse than Saliesh models? If so, how much different? Bob C: At DC, Saliesh has no phase shift, our actual measurements have 90 degrees phase shift. Sailesh: The four curves in this proposal do not exercise the clock recovery mechanism to the worst case. However, I would be willing to adopt the four curves for simulation purposes. HF: Do presentators have anything to ask the audience? Bob C: My problem with Sailesh curves is that they have not been validated against the real world. How should the group deal with this? John Doe: Any model we chose needs to be validated. Igor: What BC presented was some worst case data, but not a model. We need to have a model so we can do simulations. John Doe: There is a big difference between models and measured data. Seems that this is a problem because .......... (couldn't hear the rest of the comment) Sailesh: The measured data has been scaled up, so its effect is exaggerated. John Doe: Is there a chance to develop a time domain and frequency domain model? Pat T: Having looked at both time domain and frequency domain data over the years, the your curves have margin at mid range and have little margin at the high end. This is opposite to what we have seen on category 5 cable. Also, no phase measurements are shown on measured data and are also chaotic from our experience. Sailesh: I would like to get some measured data from others, is any available? Pat T: No data on cat 5 HF: Anybody have measured data? Howie: Measured data is complex and highly variable, so direct measured data is better than models. John Doe: Why not use cables that have spec'ed bandwidth above 100 MHz? Geoff: In comittee XYZ, if we were to give you specs for cat 5 above 100 MHz, it would no longer be cat 5 cable, so it can't be done. The Split-Band Proposal For Gigabit Ethernet Over 100m UPT-5 - Sailesh Rao This presentation described the details of a copper PHY for Gigabit Ethernet, called the split band approach. The objectives and partitioning of the split band approach were presented. A technical overview of the split band approach was then described. Then, technical details for the PCS and PMA sublayers were presented. Some simulations graphs were shown. Comparisons of the EMC performance between the split band approach and 00BaseTX in were also discussed. John Doe: What performance are you expecting form external hybrid Sailesh: Expecting 10dB max John Doe: Do you have a gate count to implement this PHY? Sailesh: Rough calculations indicate that this gigabit PHY would be about 6x lager than a TX PHY. John Doe: Do you have a power estiamte? Is everything runign at 125MHZ? Sailesh: No power estimate, some sections can run less than 125 MHz. Mike S: How would you implement 100/1000 solutions? Sailesh: Reuse the ADC, clock recovery for both, disable NEXT cancellation, line equalizer is digial and can be preprogrammed for 100. John Doe: Are there any existing systems using split band approaches? Sailesh: I believe wireless solutions have used split band. John Doe: You said you can provide margin using more taps on equalizer, but you don't have NEXT equalizers? Sailesh: We have NEXT cancellers. John Doe: But not from adjacent pairs. Sailesh: We have adjacent pair NEXT cancellation. John Doe: On worst case constellation, it looks like constellation is too big to meet S/N requirements. Sailesh: Maybe need more taps on echo canceller. (Some more comment like above question) Sailesh: I believe that there is enough noise margin. John Doe: Were any latency calculations done? Sailesh: Back of the envelope calculation shows about 30 bits of margin, but it is implementation dependent. Steve H: Could you break the bit budget down into more detail? HF: In future proposals, bit budget should be part of the presenetations and contrasted to Fibre Vhannel PHY case. John Doe: In the comparisons between split band and PAM 3x3, the comparison is not fair comparison because split band needs more channels and no comparison for number of bits is accounted for in complexity numbers. Sailesh: (Goes thru slide 16 again) (Some dialogue back and forth as to whether comparison on Slide 16 between PAM 3x3 and split band is valid comparison.) John Doe: On split band approach, aren't you doing calculations with complex numbers while PAM 3x3 uses only real? Sailesh: This is true and accounted for in the comparisons. Gigabit Ethernet Over CAT-5 UTP Cable - Kamran Azadet This presentation described the details of another copper PHY for Gigabit Ethernet, 3x3 PAM approach. Goals for a copper Gigabit PHY were presented. The use of a 3x3 constellation in the PHY was justified. An overview of the entire 3x3 PAM approach was presented. Finally, a proposed criteria for evaluating all copper PHY proposals was discussed and proposed. Jim E: What were the DFE and FFE tap length? Kamran: DFE was 4 taps, FFE was 9 taps. John Doe: On mixed mode implemetation diagram, what do switch symbols mean? Kamran: (answer can not be heard) Sailesh: 4 taps on DFE is insuffieient. Kamran: Out simulations say it is enough Sailesh: What is the coefficient precision assumed in the analog filters? Kamran: (couldn't hear answer) Sailesh: Were worst case models used Kamran: Yes John Doe: You said lower precision at higher speed was better, but isn't that affected by impulse noise? Kamran: We looked more at NEXT noise, so the requirements for NEXT increases with frequency, so that should help with other noise as well. Also, this approach should have same noise immunity as split band. John Doe: More noise analysis should be done..... Kamran: What kind of noise are you concerned about? John Doe: Maybe it has to be measured John Doe: If error rate is 10 -10, that is one error per 10 seconds, is that palatable to users? Kamran: What do you think it should be? John Doe: It seems that one error per many minutes would be a better goal. Kamran: We thought 10-10 would be sufficient JT: In terms of EMI and EMC, does compliant meand class A or B and how much margin do you have? Kamran: We don't have any measurements yet, we will do it after a prototype is made. Sailesh: Split band is whatever TX does. Kamran: EMC is dependent on common mode noise and design. Del H: How do you prevent converison of differential noise to common mode noise? Kamran: For cables, cable guys say it should be fine. For magnetics, magnetics folks say that common mode chokes and other techniques can be used to reduce noise. Sailesh: Split band uses Cat 5, cat 5 is sufficient, TX works now. (Some more discussion of emissions issues) Sailesh: It is ok to have NEXT curves that are scheme oriented because each scheme has weaknesses that only specific curves may show. Kamran: There should be some sorr to standardized NEXT models Gigabit Ethernet UTP-5 PHY - Barry Hagglung This presentation described a copper PHY proposal for both short haul and future long haul copper. This approach was described as a continuous time analog approach. An overview of the approach was presented. The usage of 4 level coding and noise immunity was discussed. A comparison of this approach to other PHY approaches was offered. Eye diagrams for the approach were presented. Frame formating and GMII proposals for this PHY were shown. An overall block diagram of the the continuous time analog approach was shown. Unfinished work needed to complete the proposal was discussed. It was noted that supplementary material, primarily related to 155 MB UTP performance, was attached. HF: What about DC balance? Barry: Two solutions. One is to use a baseline wander correction circuit for long term DC errors. Second is to take a disparity sum and invert bits when DC balance exceeds a certain value. We have some more elaborate proposals that can be discussed in future. HF: Given no excess codes, any analysis on long term DC effect on whether PLL's can stay locked? Barry: Scrambling on the frame is used and this will reduce DC imbalance. This is not perfect, but helps and more work is needed and more input is requested. We believe that there is a viable scheme that will work successfully. John Doe: Do you need multiple PLL's to recover the clock for each line? Barry: One PLL is required for one line and a DLL for the other line. HF: Because of scrambler, how is the PLL going to lock on the data? Barry: There are two scramblers, a frame scrambler and a self scrambler which keeps run lengths to reasonable values. Proposal For Coper Based Short Haul Interconnect - Herb Schneider This presentation described a proposal for a copper PHY for short haul applications. The need and goals for short haul copper interconnect for Gigabit Ethernet were described. The scheme was described as the same one that is already specified and used for Fibre Channel which relies on the use of Twinax cable and associated DB9 and HSSDC connectors. Eye diagrams for different cable lengths, with and without equalization, were presented. John Doe: Are eye patterns with full or half duplex? HS: Measurements were done with data traveling on both pairs. John Doe: Why do you think non equlaizer approach is limited to 12 meters? HS: Based on eye diagrams and experience, it seems 12 meters is the limit for unequalized cable. Geoff: Did you measure eye diagrams on short cable lengths with the equalizer? HS: That case wasn't measured, but fixed equalizer needs to be changed for about every 10 meters in length. John Doe: Is the same equalizer used on all eye diagram lengths? HS: The 30, 40 meter case used one equalizer, the 20, 25 meter used another equalizer. John Doe: What is the contribution to crosstalk on the eye diagrams? HS: No measurements were taken. John Doe: Were equalizers integrated into the cable the same ones used for Fibre Channel? HS: Yes John Doe: Will the equalizer work at 1.25 Gb? HS: Equalizers will probably have to be changed for 1.25 Gb, but the cable vendors should be able to do this. John Doe: Was impedance matching taken in account of in setup? HS: Yes John Doe: Was signal AC coupled in measurements? HS: Yes, with capacitors. No transformers were evaluated. John Doe: What is the additional cost for fixed equalization? HS: Out vendors are quoting $10-12 HDMP-1556 SerDes Chip Short Haul Coax Cable Link Performance at 1.250 GBd Line Rate - Del Hanson This presentation described the performance of the 1556 SerDes chip with coax cable link at Gigabit Ethernet speeds. The block diagram of the test system was shown. A brief description of the SerDes chip was presented. Eye diagrams for different cable lengths was presented. John Doe: On the setup, is the scope connected to the RX end? Del H: Yes, it was a single ended measurement at RX end. John Doe: Is the receiver running syncrhonous to the transmitter? Del H: Yes, both are clocked from same source. John Doe: In a normal system, both transmitter and receive would be clocked from separate sources. Del H: True Methodology for Jitter Specification (MJS) of 1Gb/s Serial Links: Status & Time Schedule - Del Hanson This presentation outlined the work and progress of the Fibre Channel group that is developing methods to measure and specify jitter. (No questions from audience.) Choosing The Right Optical PMD Solutions - Paul Kolesar This presentation outlined choices for fiber links for Gigabit Ethernet. The TAI and ISO specs for fiber were reviewed. Data on distance as a function of modal bandwidth was presented for different wavelengths. Advantages and disadvantages of possible choices for 300 and 500 meter fiber lengths was explored. The use of equalizers to improve fiber performance over distance was discussed. Final recommendations were made. JT: We have not seen as much difference between two wavelengths due to chromatic disperson, do you have data to match the graph? Paul K: The data is based on caculations. John Doe: If there is an underlaunch conditions, there is going to be a secondary improvement by the index variation of the light that will improve the chromatic dispersion. Paul K: True John Doe: How is clock recovery done with 1 tap DFE? Paul K: Clock recovery is done after this block. (Some discussion about tradeoffs with bandwidth vs distance vs. wavelength) John Doe: Wouldn't the DFE have to be fed back after clock recovery in the SerDes chip? Paul K: Yes John Doe: In order to make the DFE work, you will need wide bandwidth amplifiers between the optics and clock recovery. Paul K: Maybe true. John Doe: The 200/500 bandwidth is set by ISO, not a new requirement. Paul K: True, but the advantage to stay at 200 MHz is ...... (coudn't hear the rest of the answer) Gideon: If I am a sytem vendor who doesn;t know anything about fiber, what do I need to do to make a fiber system work? Maybe there are too many choices here. Paul K: If my proposal is adopted, there will be equivalent solutions for 850 and 990 nM solutions. Gideon: I don't want so many solutions. Paul K: Hopefuly, the standard can be written clearly enough and decisions can be made to limit the choices and make them clear. Del H: I think this is a summary of alternatives, but the real question is how to deal with the cell base. Pat T: With this proposal, 780nm transceivers will not be compatible with 850 nm transceivers, so now we need two devices. Also, this proposal is different from national and international fiber standards in terms of bandwidth and distance, which may be a problem. Third, an earlier proposal covered the national and internatial standards and chips without alteration, so why not do that? Paul K: First, 780nm transceivers are compatible with 850 nm transceivers because the proposal is to put the DFE in the 850 nm which will make them compatible. Second, we need to address the market and cost issues, and the standard needs to be accepatable to the largest user base in order to be acceptable. Optics, Update to Joint Proposal of May, 1995 - Jonathon Thatcher This presentation is an update of the fiber proposal made in May, 1995. A diagram of the layer architecture of a fiber solution along with the relevant interfaces was presented. Proposals were made for a short wavelength (SWL) and long wavelength (LWL) fiber solution. Detailed specs for the SWL and LWL transmitter, receiver, and media were presented. Mike S: The spectral width is 4? JT: The 4 is rms which is equivalent to 9pk=pk John Doe: Good starting point, more work needed. 4nm RMS width may not be narrow enough, some more work needed, but good start. JT: Agree John Doe: (Some incomprehensible question) JT: The spec numbers in the proposed specs are representative of what is being shipped today. Coupling SM-Waveguides into MM-Waveguides - Shelton This presentation discussed the performance achieved when single mode fiber was connected to multimode fiber. Methods for coupling SM to MM were discussed. Geoff : This seems to say that short jumpers should be SM. S: True HF: You cannot do that on receive side. S: Correct. You can put MM into receiver, but not SM. Del H: There are pigtails today with transceivers and safety in them that work today. (Some more discussion about this, general concurrence) John Doe: This may work for HP transceivers, but what about with other vendors? S: There are some standards that everyone complies with John Doe: If you built a LW transevier and transmit into SM fiber with safety, then all specs are met. S: Yes GEA Sponsored Customer Survey - Raymond Sit This presentation showed the results of a recent GEA survey of types of links used in Eethernet networks. Graphs of the relative usage of fiber and copper risers was presented. Distributions of backbone distances was described (No discussions from audience.) HF adjourned meeting at around 5:30 p.m. DAY THREE HF brought meeting to order at 8:35 a.m. HF said today's agenda is as follows: AOB Plans for Next Meeting Approve Minutes of July meeting Adjourn 8. AOB MOTION #1 HF: First new business is timeline for standards development. (Oral history of 1Gb from Nov. 1995 to date was recounted.) We have a looming deadline cutoff for new proposals in Nov. This cutoff date drives the rest of the standards development. Also, this cutoff date is a formal announcement to anyone that this is the last call for new technical proosals, so this is a serous date. First draft is scheduled for Jan, 97. That draft has to be reviewed in detail, and during this time, it is possible that small features can be added. We would like to get to working group ballot in July, 97. This is a key date because not much changes occur after this date and implementators traditionally start development at this milestone. Last technical change is in Sept. 97. LMSC ballot is scheduled for Nov, 97, which is the last time comments can be introduced and all outstanding comments have to be resolved. Geoff : This schedule is downhill with the wind behind it. 10BaseT was the most cohesive group and most efficient standards development. So to model 1Gb standards development after 10BaseT is a best case model, not worst case. Also, starting implementations before working group ballot is early and risky. Howie: I was checking attendance book and noticed a high percentage of new (to IEEE) members. So I want to address this to those new members who may not be familier with how things are typically done in IEEE. Below is standards hierarchy: ISO ANSI IEEE Std Board 802 LMSC 802.3 Ethernet 802.3Z Gigabit Ethernet 802.3z defines the scope of the project and generates a PAR. This was approved by 802.3 in June which authorizes this group to write a standard. If we decided to change the objectives or the scope of the project, we have to go back and regenerate a PAR and reset the process back to where we were in Ja, 96. HF: The schedule is aggressive, but I love a challenge. Bob F: I move that the group adopt the timeline shown on Howard's transparency. Bob G: Second (Discussion on Motion #1) Bob F: The standards timeline is aggressive but doable. This is the best standards group that I have seen in 20 years. Bob G: The schedule is aggressive, but we need to be aggressive to get the standard moving. HF: One question is what if we miss this timeline. The PAR says that we will have a approved standard at end of 1998, which gives us 9 months slack against this schedule. But we can get PAR extended if necessary. One reason for aggressive schedule is that many people have requested a schedule this aggressive or better. Mike S: My concern that this schedule will become "public", and what happens if we then find in 3-6 months we are behind this schedule. Should we have a public schedule that is different than this one? HF: Double set of books (laughter) Geoff: This schedule is a critical path schedule and very compressed. The process is serial, so if one milestone slips, everything behind it slips. HF: We need to educate public about slips. Dave F: I call to question. (No opposition to the call to question) HF: Everyone can vote, requires 75% approval to pass Motion #1: Adopt 1 Gbps standards development timeline (on transparancy) as schedule for IEEE P802.3z activity M: Fink, S: Grow Y: 95 N: 3 A: 6 Motion Passes MOTION #2 Howie: (Puts slide up) This is my proposal for the outline for proposed standard. This has been shown before. And questions? John Doe: What are copper jumers? Howie: These are jumpers in a wiring closet between hubs or switches. John Doe: Putting one UPT PHY chapter, does that preclude #38 being a PHY too? Howie: I will amend Chapter 38 to be PMD: Copper closet jumpers and Chapter 39 Horizontal UTP PHY John Doe: Are we being asked to accept this outline or the text on the transparancy? Howie: The entire page John Doe: We have assumed Chapter 36-38 are all 8B10B blocks, so we should change them to add that to chapter titles. Howie: OK Howie: I move that we adopt this outline for the standard (shown on my transparency). Brian M: Second (Discussion on Motion #2) John Doe: What if one of the chapters takes longer than the rest. How do we detach that clause so rest of standard is not slowed down? Geoff: In the past, some chapters have been delayed, so the standard is published with a note that that chapter is in progress. Vern L: I object putting 8B10B in front of Chap 37-39, so I propose to amend the motion to take Chap 39 and divide it into two chapters, one for short haul and one for long haul. HF: Does Howie accept this as a friendly amendament? Howie: No, because many of the contributors and members have been assuming that 8B10B is the basis for the standard HF: Does Brian MacCleod accept it as a friendly amendment? Brian: No HF: So, we have to offer this as a hostile amendment. Vern L: I move to offer a hostile amendment that clause 39 be split into two clauses: (1) Clause 39a. Long Haul UTP PHY, and (2) Clause 39b. Short Haul UTP PHY Brian H: Second (Discussion on hostile amendment) Vern L: The outline as it is now mandates that jumpers be used with coax, and other alternatives have been offered. This amendment does not preclude any approach for jumpers, coax or other copper. John Doe: Where does it say coax in chapter heading? How does 8B10B constrain the chapter to coax? Little: 8B10B would be a disadvantage for a twisted pair implementation, but would be ok for coax and fiber. Bernard I am in favor in finding UTP options that do not meet full distance, so if we can find approaches that do this, that is good, independent of whether they are coax or other type. I am in favor Mike S: Call to question HF: Any opposition to call to question? (There is opposition to call to question) HF: Since there is opposition to call to question, we have to vote on the call to question on discussion to Vern's hostile amendment: Favor: 36 Oppose: 48 HF: So call to question motion failed, more discussion can follow Geoff: This motion makes provision for other alternatives jumpers in the future, not to preclude different types, so I oppose the motion. John Doe: Coax cable is not required, twinax cable could be used as well. Pat T: Our objectives don't include two version of UTP, short and long. So without a lot of analysis on cat 5 cable, it is not appropriate to assume this as work we need to do now. If by Nov there is more work done, this outline can be modified then, but it is premature to do that now. Accepting table of contents now does not preclude changing it in the future. We should not accept table of contents now with items that are not defined Howie: The 8B10B shor haul proposals to date have been based entirely on Fibre Channel with coax and twinax. So to get to standard quickly, a lot of people wanted to adopt the fibre channel jumper strategy because it is already done, thats why we propose the 8B10B approaches for short haul. Bob G: I am opposed to this motion. We need a substantive outline now, and to date, that is the 8B10B solution. What's on the title is not as important as getting technical contributions to make the chapter. Vern L: The outline presented had 8B10B in fron of three chapters which precludes the use of other coding schemes, which other solutions have been presented. Also, the horizontal copper section should not b restricted to UTP5, because there are other solutions available. I feel the Horizontal and 8B10B restrict the content of the chapters. HF: So, let's vote on the amendment moved by Vern Litte. Voting on the amendment requires 75% approval. Motion #2a: Clause 39 in Howie motion should be split into two clauses: (1) Clause 39a. Long Haul UTP PHY, and (2) Clause 39b. Short Haul UTP PHY M: Little, S: Hagglund Y: 18 N: 25 A: 30 Motion Fails HF: We are back to main motion of adopting "Outline of Standard" as the basis for our work. Pat T: If we approve this motion, Are we agreeing to the exact chapter titles or just the structure? Howie: Yes Geoff: Same for chapter numbers Bob G: I prefer the more generic outline names........ Howie: I prefer to leave it as is. Scott: Can one of the chapters be split out at a later date? HF: Yes, spliting the PAR can be done without significantly slipping the schedule. If new projects are added, then the PAR would have to amended and would cost a few months delay. Little: Are we voting on the outline with or without the amendments in red? HF: We are voting on the outline with the amendments John Doe: The use of words "closet" and "horizontal" indicate application, while the optic chapters do not indicate their application, so why should these words be in this chapter heading? Howie: The group in Holland decided this JT: Why does Chapter 35 have both PCS and PMA layers in one chapter? Howie: These items go together, so we propose they be in same chapter. HF: 100BaseX also had PCS and PMA in same chapter, so there is a precedent. Geoff: My preference is to have PCS and PMA into two chapters, because that would facilitate using GMII to be used both below and above the PCS. HF: That level of detail may be too fine at this stage, and we can probably successfully deatl with it later. Shimon: Call to question HF: Any objections to call to question? (No opposition to call to question). HF: Lets vote Motion #2: Adopt "Outline of Standard" as the basis for our work M: Johnson, S: MacCleod Y: 80 N: 4 A: 16 Motion Passed MOTION #3 Bernard Main issue now and in future is repeater full vs half duplex. (Many slides, some funny). Full duplex has no restrictions, half duplex does. Full duplex repeater costs $5/port extra now, which is not much. So, I believe that we move forward with CSMA/CD in a box and move forward with buffered repeaters with full duplex and not worry about half duplex repeaters. Bernard I move that we adopt full duplex "buffered repeater" as the repeater for Gigabit Ethernet. Cam: Second (Discussion on motion #3) Cam: The additional cost of buffered repeater is not significant, and the work needed to get gigabit to work at half duplex is not worth it, so we should pass this motion. Geoff: believe that the buffered repeater is not a repeater but a switch. And the PAR specificatlly defines the scope of 802.3z to include repeater and not a swtich. So, to be consistent with the PAR, it is my opinion that we cannot standardize this buffered repeater because it is not a repeater. Nothing in the proposed standard to date precludes one from building a buffered repeater. John Doe: I am in support of this motion because classic repeaters will cease to exist in the future. Gadi: Buffered repeater is a cut through switch. Steve H: The buffered repeater fits inside the standard as we have envisioned it, just like switches are not currently standardized but widely employed. I think that standardizing the CSMA/CD in the box will cause turmoil. And having three alternatives will confuse the industry (switches, repeaters, buffered repeaters). I think it is a good idea, but should not be the only repeater in the standard. Alan A: The decision should be held open, Is a better time to make this decision in Nov. Rich G: The buffered repeater can coexist with a normal repeater in the draft. John M: I am in favor of the motion. The incremental cost is low enough to make a buffered repeater viable. It is new, but the time to make a change to a new architecture may be now. HF: When we started, I knew that the CSMA problem was a significant one. I worked on carrier extension because it seemed the natural way to extend CSMA/CD. To date, I have been somewhat netural, but now is the time to speak out. In Jan, Mar, And July, we voted overwhelmingly in favor of CSMA/CD. I feel that we need to change the PAR if we want to get rid of CSMA/CD (and this includes putting it in a box). This can be done, but will delay everything. Second, I feel that there is a need and a market for CSMA/CD. Even if we standardize CSMA/CD, buffered repeaters can still be built and sold. So I am not inf favor of standardizing the buffered repeater. John Doe: Can PAR be changed in 6. From "full and half duplex" to "full and/or half duplex." HF: May be some problems with Clause 28 ....... Bob F: How does motion change standard? Bernard Means that CSMA/CD not be done on the link. Bob F: I am for buffered repeater, but against anything that will delay standard. Mike S: We have heard some other proposals for repeaters other than buffered repeater and carrier extension, and I would like for some more time for these new proposals to be developed. John Doe: I like full duplex links, but I don;t like standardizing the repeater as required, because this constrains peer to peer networks. Brian M 802.3 Clause 9 (defines repeaters) states in first paragraph that repeaters might change, and allows for the way new repeaters are buitl and defined. So I believe that we don;t need to modify the PAR to standardize new repeaters like the buffered repeater. Howie: I am against the motion. Buffered repeater is not the best way to do a repeater. It is a good product idea, but not for a repeater. At 10GB, CSMA might be useless. But for 1GB, some vendors think CSMA is useful. So I am reluctant to kill CSMA/CD now since the market and vendors say it is needed. We shouldn't disallow buffered repeaters in the standard, but we should also allow CSMA as well because both CSMA and buffered repeaters can coexist. It is also the simplest course of action. Gideon: I think it is premature to replace CSMA with buffered repeaters at this time because not enough data is available on the buffered repeater. Offer: First, I disagree with the cost arguement, the cost of buffered repeater is significant burden. Second, if we adopt the buffered repeater, we restrict the ability other repeater alternatives that offer other price/performance points. Third, if we allow low end repeaters to be standardized, we allow both high end and low end equipment possible. Bernard Point to point links can be done without a repeater. Cost of buffered repeater is not as high as other estimates said. Gadi: Repeaters are very cost driven. The market needs a low cost repeater solution. The buffered repeater should not be standardized. Ray S: I am against this motion. I am concerned with interoperability with 10/100 equipement. CSMA should be allowed. Also, the extra cost of the buffered repeater architecture is a drawback. Shimon: I am against this motion. First, we are supposed to define standards that guarantee interoperability, not architectures. The buffered repeater can be built today. If we standardize it, it will preclude other architectures. HF: Time to vote Motion #3: Adopt full duplex "buffered repeater" as the repeater for gigabit Ethernet. M: Daines, S: Cam Y: 25 N: 41 A: 37 Motion Fails MOTION #4 Mike S: Carrier extension is viewed by some to be a harmful thing for 1GB, so I would like for the group to define what the CSMA performance objecives should be. So I make the following motion: Modify objective 4 to define that the single packet performance of gigabit shared topologies should be comparably high to equivalent shared topologies in a 100Base and 10BaseT. Colin: Second Dave F: Want to offer friendly amendment to change 100Base and 10BaseT to "10 and 100 Mb/s Ethernet. HF: Is this friendly amendment accepted by mover and seconder? Mike S: Yes Colin: Yes HF: Friendly amendment is accepted. Grenier: I offer a friendly amendment to change "comparably high to equivalent" to "equivalent to that provided by" HF: Is this friendly amendment accepted by mover and seconder? Mike S: Yes Colin: Yes HF: Friendly amendment is accepted. HF: So motion now reads: Modify objective 4 to define the single packet performance of Gigabit shared topologies should be equivalent to that provided by shared topologies in 10 and 100 Mbps Ethernet. (Discussion on Motion #4) Pat T: This has nothing to do with Objective 4, so I believe it will have to be added as a new objective. Also, this proposal is vague. It will be hard to get performance equivalent to older protocols. John Doe: I am not sure what this motion really means. Can movers explain it? John Doe: Can mover clarify equivalent and single packet performance? Mike S: I am concerned about the perception in the market that the CSMA performance is low. There have been some proposals that make this performance higher. I am offering an amendment that we try to increase the performance of CSMA so that it rivals that of 10 and 100 Mb Jayanti: I oppose the part of the motion that we be equivalent to performance of 10 and 100 mbps because that might defeat the objective that we do simple forwarding between 10,100, and 1000. Geoff: I believe that this motion means that we preclude carrier extension. If that is the intention, then it should be changed to say so. If not, then I don't know what it means other than carrier extension at 1GB should be same performance as 100MB which it does. Steve H There is some fear that press will assail 1GB because of low performance of carrier extension 1GB ethernet. But this has to be compared to someting else, and comparisons betweem carrier extension 1GB to other high speed protocols show carrier extension to be favorable in terms of performance. Ray S: If this motion passes, what is the impact to the schedule for the standard? HF: Minor delay. Geoff: Call to question HF: Any objections to call to question? (No objections) HF: We are ready to vote Motion #4: Modify objective 4 to define that the single packet performance of Gigabit shared topologies should be equivalent to that provided by shared topologies in 10 and 100 Mbps Ethernet. M: Salzman, S: Mick Y: 6 N: 56 A: 18 Motion Fails MOTION #5 Kolesar: I propose the following motion: Modify objective 11C to read: at least 3 KM on single mode fiber. Bob F: Second. Gadi: Why was the original objective 2km to begin with? Geoff: Existing standard says "at least" so we don't need to change this objective to do 3km distance. Kolesar: This motion will make sure we get to 3km Del H: The current power budget will support 3km, but not larger. Geoff: How does this motion align with current standards? If this is not a constraining item, I am not opposed to it Moore: Call to question HF: Any objection to call to question? (No objection) HF: Let's vote Motion #5: Modify objective 11C to read: at least 3 KM on single mode fiber M: Kolesar, S: Fink Y: 47 N: 2 A: 29 Motion Passes HF: Due to large number of abstentions, I request that all members review this action, make sure this doesn't cause any problems, and report back in Nov. MOTION #6 Charles H:I want to make the following motion: Any copper PHY proposal must include sufficient informatin for others to simulate and verify the claims of the proposal. This information should at least include: * Functional Block Diagram * Analog converters, # bits, speed, linearity * Analog filters: type, order, cut-off frequencies * Clock recovery scheme * Digital blocks: # bits for data, coefficients, data path, number of taps * Initialization procedure, adaption algorithm, update accuracy Moore: Second (Discussion on Motion #6) CH: I think an evaluation criteria needs to be developed so that we can evaluate copper PHY solutions. This motion is a proposal to establish that criteria. Moore: The presentations to date for copper PHY's were lacking critical information to make informed decisions. Thus, this motion is appropriate. Howie: This seems to be motion that pits one side against the other. I ask that the mover retract the motion. John Doe: Generating this information is required for any third party to verify the results of a proposal. Sailesh: Some of the information mandated by the motion if more educational and maybe proprietary, thus unnecessary. Geoff: A list like this should change for each implementation. As such, a the list has to be dynamic to be effective. We shouldn;t have to mandate this kind of information, each presentor should offer the appropriate information as part of their proposal. Pat T: Nothing in the motion is biased for or against a specific implementation. Information like this is necessary for the group to make good decisions. Sailesh: The reflector can be used to resolve technocal issues. A motion like this is unneccessary. Raveal: This information is needed to verify proposals. But, there shouldn't be a motion making this a requirement. This information should be traded freely among members. Tang: I move that we postpone acting on Motion #6 until after technical presentations have been heard by P802.3z during Novemver, 1996 Plenary session. Speiser: Second (Discussion on Motion #6a) John Doe: I would rather deal with it now and not waste time in Nov. Pat T: We should decide it today so it can apply to proposals in Nov. HF: We need to move on these decisions to meet our schedule. HF: Let's vote. HF: T This is a procedural vote, only needs >50% to pass Motion #6a: Postpone (Motion #6) until after technical presentations have been heard by P802.3z during November, 1996 Plenary session. M: Tang, S: Speiser Y: 3 N: 59 A: 7 Motion fails HF: Back to main motion. HF: We have a lot of work to do. The copper PHY proposals have a long way to go. The copper PHY proposers should focus on the technical content of the proposals, not the procedural rules around the proposals. Speiser: Call to question HF: Any objections to call to question? (No objections) HF: Let's vote on main motion, this is a technical motion, needs 75% to pass. Motion #6: Any copper PHY proposal must include sufficient information for others to simulate and verify the claims of the proposal. This information should at least include: * Functional Block Diagram * Analog converters, # bits, speed, linearity * Analog filters: type, order, cut-off frequencies * Clock recovery scheme * Digital blocks: # bits for data, coefficients, data path, number of taps * Initialization procedure, adaption algorithm, update accuracy M: Hochstedler, S: Moore Y: 19 N: 38 A: 20 Motion Fails MOTION #7: Motion: Move that we notify X3.T11 that P802.3z has adopted the following plan of action. M: Johnson, S: Hanson Y: 49 N: 0 A: 7 Motion Passes MOTION #8: Motion: 802.3z Task Force endorses the designation of Richard Taborek as the official liaison between P802.3z and ANSI X3T11. M: Fink, S: Van Doorn Y: 56 N: 0 A: 5 Motion Passes 9. PLANS FOR NEXT MEETING The next meting is at IEEE Plenary, Nov. 11-15, Vancouver, BC. Details on Web page Howard Frazier asked the group to take an informal vote on whether to have one big group meeting in Vancouver, or to divide the meeting into tracks, or subgroups. The informal vote indicated the group wanted to break the Vancouver meeting into tracks. Then, an attempt was made to ascertain level of interest in each track. A tabulation was taken on which track everyone would attend as a first priority. Results are as follows: 34 Repeater Track 6 MII Track 12 PCS Track 7 Long Haul Copper Track 4 Short Haul Copper Track 6 Optics Track Based on the above results, HF proposed the November track meeting be divided as follows: Track 1: MAC/PCS/MII Track 2: Long Haul Copper Track 3: Short Haul Copper/Optics (8B10B PMA/PMD's) Then, HF requested an informal vote on when to start the track meetings in Vancouver. The informal vote indicated that the group wanted to start the track meetings on Monday morning. HF mentioned that each track will need facilitator, and very quickly the group will be a need to identify sub-task force leaders and clause editors. HF said that based on these informal votes, he will work on detailed schedule for the November meeting. 10. APPROVE MINUTES OF JULY MEETING Some changes to the July meeting minutes at Enschedes were proposed. CHANGE #1 Howard Frazier: Under EMAIL REFLECTOR AND WEB/FTP SITE section, the second reference to the email reflector should be changed from "stds-802-3hssg" to "stds-802-3-hssg". (No discussion) CHANGE #2 C. Hochstedler: Motion #5 did not fail, but was tabled, i.e. not voted on. So the correction to the minutes should be, "Mr. Shimon Mueller made a motion to table the motion, which has approved.", and delete the statement that the motion failed. (No discussion) CHANGE #3 Moti Weizman: Change the description of my technical presentation to read as follows: Moti Weizman - HSSG CSMA/VCD(tm) proposal Mr. Weizman presented a proposal to improve system operation through the use of virtual collisions and frame batch. The proposal supports operation over a collision domain of 200 meters with performance effected little by the frame sizes, twice the network diameter before carrier extension is required, no loss of bandwidth when a collision occurs, and guaranteed fairness. (Much discussion, some disagreement with Change #3) Moti: I move to amend minutes according to Change #3 above. Offer: Second (Discussion of Change #3) Bob G: I want to amend the motion as follows: Delete the phrase "and guarantee fairness" and add the sentence "The discussion included concern about fainess in access." Pat T: Second HF: Does the mover and seconder accept the amendment as friendly? Moti: No Offer: No HF: Then the amendment is a hostile amendment (Discussion of hostile amendment to Change #3) Offer: The hostile amendment is an opinion, not something that was presented, it is misleading. The minutes should capture what was discussed at the meeting, and the hostile amendment was not talked about at that meeting. Thus, the hostile amendment should be voted down. Moti: There were no comments at the meeting that the scheme presented was unfair, thus the amendment is incorrect. Geoff: Was there or was there not a discussion about fairness to access? Moti: There were some comments Geoff: So there was a discussion Howie: I rember the scheme having some unfairness. Kevin D Moti's presentation said that fairness was guaranteed. There was some discussion by others that this may be not true. So, why not include both points of view by adding in the phrase "and guaranteed fainess": HF: How about this as a friendly amendment? (Moti and Offer do not accept this as a friendly amendment) Howie: Call to question HF: Are there any objections to the call to question? (No objection) HF: So we now vote on the motion on adding the amendment to Change #3. Motion: Amend Change #3 as follows: Delete the phrase "and guarantee fairness" and add the sentence "The discussion included concern about fainess in access." M: Grow, S: Thaler Y: 25 N: 0 A: 6 Motion Passes HF: So, we go back to main motion, and that motion is changed as follows: Motion: Change the description of Moti Weizman's technical presentation to read as follows: Moti Weizman - HSSG CSMA/VCD(tm) proposal Mr. Weizman presented a proposal to improve system operation through the use of virtual collisions and frame batch. The proposal supports operation over a collision domain of 200 meters with performance effected little by the frame sizes, twice the network diameter before carrier extension is required, no loss of bandwidth when a collision occurs, and guaranteed fairness. The discussion included concern about fairness in access. M: Weizman, S: Iny Y: 18 N: 0 A: 10 Motion passes HF: So Change #3 is amended accordingly. Motion: Approve minutes as corrected (for the above three changes) and update the copy on the FTP archive accordingly. M: Fink, S: Quackenbush Motion passes by acclamation ADJOURN HF: Any other business Dave F: We should thank Packet Engines for a job well done (Big round of applause) HF adjourned meeting at 1:20 p.m.