Minutes of the IEEE 802.3z Gigabit Ethernet Task Force ****************************************************** Vancouver, British Columbia, November 11-14, 1996 ************************************************* (Note: where a minuted item was by a person unknown to the secretary, the entry will be ascribed to "Unknown" in the minutes) The meeting was brought to order Monday morning by the Chair, Howard Frazier. The proposed agenda for the meeting was distributed. 1. Introductions **************** Each attendee stated their name and corporate affiliation. There we approximately 150 attendees at the opening of the meeting. 2. Minutes Secretary ******************** The Chair picked Dave Fifield to volunteer to record the minutes of this meeting. 3. Status Report **************** The Chair gave an update of the current position of work and stated the voting rules for this meeting. 4. Email Reflector/Web Site *************************** The Chair provided detailed information for subscribing to the email reflector. 5. Timeline *********** The Chair described the adopted timeline, where we were currently on it and what was required in order to keep on track. This included the fact that all new proposals would have to be placed before the Task Force now, this meeting, or they could not be considered. 6. Objectives and PAR ********************* The Chair reminded the optical community of their promise to check the adopted single mode fiber distance of 3Km in objective 11c. The Chair emphasized the title of the PAR and the scope of the project once more. 7. Document Distribution ************************ 40 copies of the Coeur D'Alene September Interim meeting's minutes were distributed to attendees who needed them. At this point in the proceedings the Chair explained the rest of the proposed agenda. The proposal was to split into 4 separate tracks in order to de-serialize the presentations and fit all the work into the meeting time available. The 4 tracks were: Track I - System/Repeater/MAC Moderator - Stephen Haddock - GMII Moderator - Bob Grow - PCS Moderator - Rich Taborek Track II - Long Haul Copper PHY Moderator - George Eisler Track III - PMA/Optical PHY Moderator - Jonathan Thatcher Track IV - User Requirements Moderator - Howard Frazier The proposed track agendas were presented. Since time was at a premium, strict timekeeping would be adhered to for all presenters. Enforcement would be ensured using a large handbell. Bob Fink was made official timekeeper for the meeting. Bob provided an adequate demonstration of the bell! The Chair then asked if there were any changes or additions that anyone wished to make to any of the proposed track agendas. Track I: Jayant Kadambi withdrew his presentation number 12 (ovation). Moti Weisman withdrew his presentation number 7 (more ovation). Haluk Aytac added a 10 minute presentation entitled "Timing Analysis of Option C Clocking Scheme" to the GMII section (muttered disapproval). Track II: There were no changes to the Track II presentations. Track III: Del Hansen and David Cunningham agreed to swap over presentation slots in order to smooth the information flow of this Track. Track IV: There were no changes to the Track IV presentations. The Chair worked out a room schedule for each of the Tracks with input from the Moderators and attendees. A minimal overlap plan evolved. The Chair promised to publish it by Monday pm. A motion to adopt the proposed agenda was then entertained. Moved: Bob Fink Seconded: Rich Seifert Approved by acclamation 8. Technical Presentations ************************** Minutes from the four tracks are presented in this section. They are not in any chronological order and have been edited to follow the section numbering scheme of the overall IEEE 802.3z minutes. 8.1 TRACK I System/Repeater/MAC/GMII/PCS **************************************** 8.1.1 Architectural Overview **************************** By Dr. Howard Johnson of Signal Consulting Inc. Howie handed out copies of the "Reprint Book" and explained that it has no official status (it is not a "Blue Book). The companies named inside the cover do not necessarily agree with all the contents of the book, they are merely indicating that they consider it a worthwhile effort. The GMII and short haul copper links presentations are missing from the Reprint Book. Howie showed the evolution of Ethernet in graphical form for families of products: shared, switched versus aggregate system bandwidth. He stated that we wish to duplicate the move from 10 to 100Mb/s as we move from 100 to 1000Mb/s. He indicated the inherent system problems in doing this for shared Ethernet (e.g. the collision domain size) and pointed out that if we allowed asymmetric flow control at 1000Mb/s, a family of full-duplex repeater products (called "buffered distributors") could be built with good price/performance ratios. Howie then showed the proposed layering of the 1000Mb/s Ethernet stack based on the successful 100Mb/s standard and how this leads naturally to the organization of the new standard as proposed in the Reprint Book. At the end of Howie's presentation, control of the meeting was passed to Stephen Haddock, the moderator for Track I. Howie's presentation was taken prior to the official start of Track I; this minor order error was ignored and we proceeded straight to the next Track I presentation: 8.1.2 Gigabit Buffered Distributor Proposal ******************************************* By Bernard Daines of Packet Engines Inc. Bernard described the cost/performance benefits of a full-duplex buffered repeater architecture. He described its operation using packet based flow control. He pointed out that many architectures were possible (such as dual FIFO's, alternate arbitration schemes etc.) He stated that this proposal needed asymmetric flow control to work correctly, and that this was the only standards effort required to allow products of this type to exist. He stated that his purpose was just to bring people up to date with his work and he wanted to know if this type of device was interesting to the group. He presented some simulation results showing that a round-robin arbitration scheme had better performance than CSMA/CD based arbitration. Howard Frazier raised a question about similarity in the number of XOFF frames for max/random/min sizes of offered load and Bernard agreed this couldn't immediately be explained, saying he would investigate this further. Other questions were as follows: Q. What is the meaning of "contentions" on your graphs? A. These are what would have been collisions if the CSMA/CD arbitration scheme had been outside the box. Q. How many ports did you use in your simulations? A. 12 ports. Q. Would this (level of performance) be feasible with all 12 ports at maximum traffic? A. The maximum throughput of any gigabit hub is 1Gb/s. Q. What was your input buffer size? A. 10kbytes per port, and we didn't simulate any other size. Q. What was your output buffer size? A. The sims were done with 0, small and big FIFO sizes. A 6kbyte output buffer plus 10kbyte input FIFO with the TX/RX circuitry and flow control is a very small and cheap amount of silicon (>$10 in the future) and as such, means we are not interested in half-duplex at all. Q. Do we only have to standardize asymmetric flow control? A. Yes. This can be neGadiated using a configuration bit or bits in the start-up procedure. More will be presented on this by other people later. Q. Will outgoing flow control messages interrupt the normal flow of incoming/outgoing frames? A. No. Since it's a full-duplex scheme there's a clear (free of traffic) backchannel to send the flow control messages on. Q. How much of the 1Gb/s traffic is flow control versus real traffic? A. The amount of flow control traffic is not an issue we need to address, since we are not standardizing this idea (it's an implementation issue only). Q. Shouldn't the input and output FIFO's be the same size? A. No. The output FIFO can be real small, in the order of 128 Bytes, for the system to work successfully. Q. What happens if a buffered distributor port receives a flow control message? A. This may stop the device since the core will backup and send flow control messages to all its ports. This can result in deadlock (and is why this architecture requires asymmetric flow control). You could put a timer in to clear up this deadlock situation, but that would end up with packets being dropped. Q. Couldn't the box just drop frames altogether? A. Yes, it would still work, but it is not 802.3x (frame based flow control) compliant. Q. What about existing 100Mb/s devices, how would these work with flow control (and buffered distributors)? A. The buffered distributor architecture is for 1Gb/s not 100Mb/s. At this point, the Moderator interjected to ask that questions regarding asymmetric flow control be deferred to the relevant presentations later. Q. On a 3Km link, is a 10K buffer enough? A. It should be, certainly it is enough for a 2Km link, but may need to be increased a little for 3Km, we'd have to look at the math. Q. But at 3 bits/meter at 3E8 m/s (speed of light) the 3Km cable alone is 18K bits....? A. The buffers are 10K *BYTES* not bits. Q. (If this is not to be standardized) Why are we having this discussion? A. We leave buffer size up to the implementer. No more questions on flow control or buffer sizes please. Q. Can you cascade these devices? A. We may not want to do/say anything else in the standard other than asymmetric flow control. Q. Can you join 2 buffered distributor ports? A. Same as above, we'll leave the implementer to decide these things. 8.1.3 Flow Control for Gigabit Ethernet *************************************** By Henry Hsiaw of MMC Networks Henry showed what considerations need to be taken into account when designing a flow control scheme. He stated that priority traffic will be delayed or not get through if 802.3x pause frame flow control is used. He compared 802.3x to the Fibre Channel credit based flow control scheme. He stated that 802.3x was not so good and would maybe cost more than the Fibre Channel method and that we (802.3z) should consider this as the Gigabit Ethernet flow control method. Q. Wouldn't this proposal delay the Gigabit timeline? A. It would add a month or so. Q. How many meeting cycles would this be? A. Can't say exactly, maybe 2. Statement. There are no priorities in Ethernet, otherwise 802.3x would have addressed this. Reply. True, agreed, it's not fair to compare them (Ethernet and Fibre Channel). Q. There is *no* difference in the ability of Fibre Channel mechanisms to support priority, right? A. Yes, agreed. Q. Silicon (for Gigabit Ethernet) is likely to be pad limited, not die size limited so the argument is moot about memory size, right? A. May be so. The gate count is likely to be comparable. (There was some fast banter between the presenter and an attendee at this point: too fast to capture/understand so it didn't make it into the minutes properly. It was about buffer requirements; they agreed to disagree in the end.) 8.1.4 802.3x and Asymmetric Flow Control **************************************** By Rich Seifert of Networks and Communications Consulting Rich gave a basic explanation of 802.3x operation and answered several fundamental questions on its behavior. He then explained what asymmetric flow control was and how it might operate within the standard. Q. You seem to have on 2 hats. One 802.3x and the other as an asymmetric flow control advocate? A. True, it's my personal belief that asymmetric flow control is good and required for end stations. Q. What is the combination of asymmetric flow control required (for the standard)? A. The intent is for the MAC client *or* the MAC to be able to throttle traffic independently. 8.1.5 Asymmetric Flow Control and Gigabit Ethernet ************************************************** By Bill Bunch of National Semiconductor Corp. Bill proposed that we add an ASM_DIR bit to Auto-Negotiation. This is backwards compatible with existing 802.3x Auto-Negotiation. Bill opined that stopping traffic at its source is the only real solution to the backup problem, and since it is not a good idea to have an end station slow down the whole network (Bill used the example of a mythical ISA Gigabit Ethernet card), asymmetric flow control should be allowed. Bill presented all the system ramifications of having asymmetric flow control including the fact that it would not be a good idea to have it between switches since it places an undefinable burden on the switch designer to add more buffering. Q. How would you disallow asymmetric flow control between switches? A. By policy only. Q. What's to stop someone from doing it though? A. Policy, and the fact that the market would not readily accept a product that behaved in this way. Q. I see two ways forward. Either we a) disallow end stations to generate pause frames or b) make Gigabit end stations respond to pause frames. Agreed? A. Agreed, but another way is to do nothing at all since end stations may cope. Q. (4 minute ramble that I could not follow - I think the questioner was proposing changing the way the Auto-Negotiation bits worked or adding yet another) A. The addition of the ASM_DIR bit and the encoding chosen ensures that the scheme works for products with legacy Auto-Negotiation too. 8.1.6 Implications of Asymmetric Flow Control ********************************************* By Paul Woodruff of Bay Networks Paul's presentation looked at the overall end to end client <-> server mechanism. Paul felt this was necessary since the user is basically unaware of all intermediate devices. He wanted to understand (from the switch designer's point of view) what the effect of adding asymmetric flow control was to system requirements (buffer size etc.) and how it affects customer expectation of smooth and optimized application operation. Paul presented his method and asked for input from other interested parties. Q. Can you clarify the case without pause that actually works as a network? A. (not clear, since this question generated a fast paced discussion between Howie, Rich Seifert, Paul and others which eventually ended in agreement that there were some interesting and complex issues still to be resolved, for example, how flow control would interact with the higher protocol layers) 8.1.7 Review and Update of the Carrier Extension Proposal ********************************************************* By Howard Frazier of Sun Microsystems Howard presented the development history of the carrier extension proposal. Changing the packet size sounded simple but in reality it was complex since the bit budget and collision domain size "break". At 1000Mb/s we can use carrier extension to increase the frame time hence collision domain diameter for half-duplex. Howard skipped the detailed Pascal changes descriptions since there were no questions on them. He explained the process he undertook to produce the "Workgroup Average" traffic pattern that is being used as a test/simulation standard for proposals. Q. What length of time was used to take the results? A. We took two sets of results, one at night, the other at day since there appeared to be two distinct traffic patterns - work during the day and backups/batch jobs during the night - then averaged them to get the result. 8.1.8 802.3z CSMA/CD Repeater ***************************** By Stephen Haddock of Extreme Networks Stephen wanted to finalize the Gigabit Ethernet bit budget. His goal is to generate the new clause 41 based on the 100Mb/s clause 27 with input from the group. He had taken input from the Coeur D'Alene meeting and pointed out the changes that this made to his original presentation. He commented how unusual is was to have bits spare to "dish out" to worthy causes! The UTP PHY bit budget numbers he used are his best guess and will need to be reviewed by the Track II people. Q. Is there a technical problem in doing a 32bit MAC/PCS implementation? A. Things (bit budget usage) grow fast! The latencies go outside of 512 bits. Q. This is an IPG shrinkage question. What happens when the transmit preamble overlaps idle (sorry, I didn't capture all the question here)? A. As far as the bit budget goes this is no problem. You can delay the start of preamble OK. Q. In a 16bit PCS, will SOP be delayed by 1 byte to allow for IPG shrinkage? A. The first packet will be delayed (not a problem). Does it accumulate over many packets? No. Q. IPG shrinkage is important for copper PHYs. This will require more discussion in Track II. A. Yes, agreed. This concluded the morning's business: the meeting was adjourned till after the 802 and 802.3 opening plenaries. The meeting was reconvened at 4:45pm. 8.1.9 Packet Bursting ********************* By Mohan Kalkunte of AMD Mohan presented the work of several prominent members of the task force. He described the prior work (packet packing) that had led to this new idea and how the major problems (such as multiple packets being dropped in a collision and the management statistics delay issue) were overcome by using the new scheme. Mohan presented extensive system simulation results showing the improvement in network bandwidth utilization achieved using packet bursting. He stated that the only changes/additions to the standard required to allow packet bursting would be a burst length timer, a change to a transmit state variable and a receive flag. (Some questions and answers were lost because the questioners did not use the microphone or the presenter did not repeat the question. Sorry, I did try to get them to slow down and do this but was largely unsuccessful) Q. Are the graphs you show in log base 2 or 10? A. They should be log base 2 - it's an error, sorry. Q. How do you keep track of the number of packets in a burst, some may have more than 2, some less, therefore the 95th percentile curve is not a real world representation is it? A. The fact that there are 2 queued packets does not mean they both get transmitted in a burst. Q. Can a burst of packets be 3 or 4, not just 2? A. Yes, they can have 3 or more, but we're just showing the graphs for 95% of bursts containing 2 or less packets. Q. Is the workgroup average the same as Howard Frazier presented earlier? A. Yes. Q. Did you pick packet sizes to take advantage of packet bursting? A. No. Whatever the size of the next packet is, if it gets bursted, it goes. Q. Do you need to pre-compute if the burst length timer expires if you send that packet? A. No. You can transmit another *any sized* packet if the burst length timer isn't expired. Q. If this different than packet packing/padding, and if so, what's the difference? A. (Yes, it's different) Packet packing put extra packets within the slot time, so a collision hit one *or more* packets. Packet bursting guarantees that the second and subsequent packets do not have collisions by putting them after the slot time. Q. Seems like a good idea to modify this process to less than 1518 bytes to help some protocols....(?) A. (?) Q. If using an IPX workstation, this won't help at all will it? A. This is mainly a benefit for systems using repeaters fanned out from switches. Q. Have any studies been done for transaction based protocols and the performance advantages specifically for them? A. This is the next piece of work planned. Stay tuned. Q. How do you handle transmit statistics when there's a late collision? A. Mart (Molle) will handle this in his presentation next. 8.1.10 Pascal Changes to Support Packet Bursting ************************************************ By Mart Molle of the University of California, Riverside Mart presented the new constants and variables, and changes to the transmit Pascal required to implement packet bursting. Q. If your transmit experiences a late collision in a burst, how many do you increment your collision counter by? A. 1, since you have only seen one collision. Q. Bursting is like a way of making Ethernet pack packets on a link..... Ethernet has non-constant delay exacerbated by the capture effect. Won't packet bursting make this worse? A. Please refer to Mohan's foils (see 8.9). It doesn't cure the capture effect, it's 8X worse in fact, but bursting results in better performance all round. At this point in the proceedings Bob Grow took over the task of Moderator for Track I GMII presentations. 8.1.11 Gigabit Media Independent Interface Proposal *************************************************** By Bob Grow of XLNT Designs Inc. Bob presented the logical interface with updates and changes to the pin name mapping and timing diagrams based on feedback from the Coeur D'Alene meeting and email reflector inputs. Comment. It doesn't really matter if TX_EN is re-asserted for TX Jam does it? It's totally unnecessary. Comment. But this would break the coding scheme. You'd have to open the reserved codes. Q. Would you comment on how the timing diagrams would be affected, if at all, by packet bursting? A. Howard Frazier will be giving a presentation on that very topic later on so please let's defer the issue till then. 8.1.12 GMII Timing and Electrical Specification *********************************************** By Asif Iqbal of Sun Microsystems Asif presented some ideas as to how successful TX clocking might be done across the GMII to ensure compatibility with the old MII, the 10bit SERDES interface and future long haul copper PHYs. He presented some preliminary proposed figures for skews, delays and set-up and hold times that might be appropriate for a GMII specification. Note that the GTX clock buffer on his foil 5 of 12 incorrectly shows an inverted output. The timing numbers presented assume a 2X speed increase from slow to fast silicon samples, which he asserts is a typical industry-wide accepted number. Q. For slow path (silicon) you're bundling input buffer delay with the input buffer delay? (huh?) A. Yes. Q. Isn't that exceptionally fast for CMOS? A. In my experience this is OK. I have used an SRAM in 0.5um CMOS that has this timing as standard. For 0.35um CMOS, these numbers will be perfectly acceptable. Q. I'd like to know whose ASICs you are referring to? A. (No answer - Asif, you need to supply an answer here, people want to know). Q. I didn't understand the flow from the source synchronous clock to global sync. (D2 distribution)? A. We are showing compatibility to the Fibre Channel 10bit specification. Q. (With reference to page 9 of 12) I'd think that the static phase error of the MAC's PLL would introduce *more* clock skew, not the same. How come you use the same number? A. Measurements on a real system I have built suggest this is not a concern. I put the skew outside of the numbers for page 8 of 12. Q. The 10 bit Fibre Channel specification states the set-up and hold times including the SERDES clock skew. A. I'd be surprised if this was the case. Let's check off-line. Q. (With reference to page 11 of 12) If the worse case rise and fall time 2.4ns? A. Yes. Q. Will the 600mV at 1mA Iol meet the first incidence switching requirement? A. I'll look into it, we need to meet this requirement. Q. Why do we constrain ourselves to supporting 5V technology, given its likely fate in a couple of years? (everything will be in 3V CMOS) A. We want to keep the flexibility of designing using products for MII. Q. Are you endorsing some set-up and hold times? What are you recommending? A. My attempt was to present it and demonstrate that it is do-able and that 8ns cycle times will be OK. Q. But the MII specification puts some real constraints on set-up and hold times, will we do the same? A. The MII set-up and hold times are just a recommendation. Q. Beware, 0.35um and 0.25um is only 5V input tolerant compatible (in its I/O levels). Below 0.25um, 5V compatibility becomes impossible. A. (No clear answer could be ascertained) Q. You didn't get my point. 5V will *fry* the I/O's on 0.35um and 0.25um CMOS 3V devices. A. I don't think there is a problem. Let's take this off-line. Q. In the single PLL solution, what's the delay element in the MAC? A. It's a delay to match the board delay. 8.1.13 Timing Analysis of Option C Clocking Scheme for Gigabit Ethernet *********************************************************************** SERDES and MAC Devices ********************** By Haluk Aytac of Hewlett-Packard Haluk presented a complex mathematical analysis of the timing of Option C (refer to the Reprint Book and/or IEEE 802.3 High Speed Study Group email reflector archives). There were no questions for Haluk. At this point in the proceedings Rich Taborek took over the task of Moderator for Track I PCS presentations. 8.1.14 Gigabit Ethernet 8B/10B PCS Change Summary, Rev 5. ********************************************************* By Rich Taborek of Amdahl Corp. Rich presented the changes that have been made to the PCS coding proposal in the Reprint Book. There was some discussion on link errors (these are serious errors only - bit errors are not included on this foil). Rich promised to clean up the foil for next time. No more changes are planned and this version will be offered as the basis for the first Gigabit Ethernet standard. 8.1.15 Preamble Replacement *************************** By Linda Chen of Sun Microsystems Linda presented the problem of byte alignment from MAC to PCS on transmit given the long word (16 bit) ordered set PCS coding scheme we are adopting from Fibre Channel. She presented two possible solutions and recommended one of them to the group - the preamble as transmitted from the PCS to the PMA may be shortened by one byte to permit completion of the "idle-in-progress" before it sends start of frame. 8.1.16 Impact of Packet Bursting on GMII and PCS ************************************************ By Howard Frazier of Sun Microsystems Howard showed that the system works fine and remains robust, requiring no changes or additions to the PCS coding. It will require the addition of one flip-flop and one gate to the hardware for data_valid derivation. Derived "Receive_data_valid" (inside the MAC) dips for 1 clock during 'S' at the start of the second packet, but, with a little clever design work, implementers can gain back all the IFG that would have been lost. 8.1.17 Auto-Negotiation and Gigabit Ethernet? ********************************************* By Bill Bunch of National Semiconductor Corp. Bill debunked several widely held myths about Auto-Negotiation. He proceeded to show that, since the fiber interface uses a "new" (not RJ45) connector, we have a clean slate to define Auto-Negotiation anew for Gigabit Ethernet. For example, the arbitration state machine can be reduced in complexity and speeded up, and parallel detection can be done away with, since it does not apply to Gigabit Ethernet. Bill suggested ways in which Auto-Negotiation could be incorporated into, leveraged by or pointed to by the Gigabit Ethernet standard. Q. Do you anticipate Auto-Negotiation for copper Gigabit will be the same as for fiber? A. I assume that any copper solution will use Auto-Negotiation as it is today. 8.1.18 Simplified PCS Proposal ****************************** By Mike Salzman of Madge Networks and Igor Zhovnirovsky of Digital Equipment Corp. Igor started by explaining how complex he thought the current PCS proposal was, pointing out the 7 defined character sets and a lack of error robustness. Mike presented a proposal for a simplified Auto- Negotiation scheme that uses 802.3z frames under MAC control. Igor presented perceived issues with the current link startup procedure. Mike and Igor then went on to propose a new coding scheme for the PCS that used only 5 defined character sets. Q. (re-page 2) How does this contradict the functional requirement? A. The preamble is explicitly excluded from the robustness calculations. Several questions and answers were lost due to this scribe not being able to hear them clearly - people did not use the supplied microphones! Q. The existing PCS proposal doesn't restrict the architectures of bit level repeaters, does this? A. No, we propose the single ENDEC solution. The presentation ran out of time to be completed properly. 8.1.19 Link Startup - Proposed Modification to PCS Proposal *********************************************************** By Wen-Tsung Tang of 3Com Corp. Wen proposed some changes to the startup protocol. He proposed that we send remote fault bits from the "next page register" in the 'C' codes. He presented all the changes to the link startup procedure and transmit and receive state diagrams required to accommodate this. Q. Do we really need the timer for ACK? A. Yes, (produced a handwritten diagram) and explained why. This was the official end of the Track I presentations. The Chair asked for any other questions for any of the presenters: Q. (Howie to Steve Haddock) What will the effect of changing the byte boundaries (as per Linda Chen's presentation) be on the bit budget. A. I'm not sure. I will research this. Howie then asked Bill Bunch a question about asymmetric flow control, but I missed both the question and the answer - someone came up and spoke with me at the critical point! Q. (Rich to Asif) Can you get some 0.35um library simulation data for the propagation delay requirements? A. Asif responded by inviting silicon ASIC manufacturers to input feedback. Bob Grow asked if presenters can check with their ASIC suppliers/people. Howard will help to drive this. Q. (For Asif again) With 2ns rise and fall times, this eats about half of the duty cycle, what's the impact? A. All timing parameters have been closely scrutinized and reflect current working practice. There's no reason why it shouldn't work. Q. (John McCool to Mike Salzman) How will the MAC negotiation frames be handled by a repeater - would the repeater need to filter them out (in the MAC control layer)? A. The MAC control layer will have to be present in repeaters anyway. Q. (Howard to Mike S.) In fact, to support this, the whole MAC will probably have to be included in a repeater port. Q. (To Mike S.) Please clarify the MAC entity required for repeaters? A. (Not clearly answered) 8.2 Track II Long Haul Copper PHY ********************************* Notes from Long Haul Copper meeting 10:30-12:30 13/11/96 Chair: George Eisler Default Secretary: Colin Mick (arrived at 10:30, meeting in progress--assumed role of secretary) At this point the group was beginning a discussion of objectives based on slides showing the 802.3z objectives and a slide of proposed objectives prepared by a group of volunteers. From discussion with participants, it appears that previous discussion had focused on creating a PAR which would separate the Long Haul Copper group from the rest of 802.3z as per presentations on the previous day by Howard Frazier and Geoff Thompson. Discussion of objectives follows Motions made during this discussion-- 8.2.1 MOTION 1 Move that the long haul copper group set as a specific objective performance over a 100 meter 4-pr Class D CAT5 channel as specified in ISO/IEC11801 (1995) and EIA/TIA568 (1995) M--Bowers Second--Mick Y--48 N--6 A--0 PASSED 8.2.2 Motion 2 That this group set an additional objective of performance at least 25 meters of 4 pair Category 5 UTP for equipment room jumper interconnect applications. M Iain Verigin S Bernard Daines call question--Joe Pelissier Question vote Y-28 N-13 Motion 2 vote Y--9 N--40 A--4 FAILS OBJECTIVES FOR PHYSICAL LAYER SPECIFICATION ******************************************* 1. Comply with specifications for GMII of 802.3z. 2. Provide line transmission which supports full and half duplex operation. 3. Must provide FCC Class A/CISPR or better operation 4. Motion re 100M operation 5. Bit Error Rate of less than or equal to 10-10 6. Support Auto-Negotiation (Clause 28) 7. Identify appropriate susceptibility requirements 8. Support the objectives of 802.3z as of 13 November 96 Accepted 8.2.3 Motion 3 Move group adopt the 8 objectives identified in accompanying document & Nov 96 version of 802.3z objectives. M--CKM S--Bowers Y 48 N 1 A 0 Pass The discussion shifted to the need to generate a motion re establishment of a PAR. 8.2.4 Motion 4 The Long Haul Copper sub-task-force request that The 802.3z task force request that The 802.3 Working Group authorize the 802.3z to produce a PAR with supporting documentation, to facilitate the establishment of a separate task force to conduct the standards work on the long haul copper PHY and that the 802.3z task force forward this PAR and supporting documentation to the IEEE802 Executive Committee at least 30 days in advance of the March 1997 802 meeting for consideration at the March 1997 IEEE Standards Board Meeting. M--Mick S--Charlie Hochsteader Call motion--Lloyd Oliver Y--48 N--1 A--2 Pass Colin Mick and George Eisler to assume respnsibility for drafting PAR & 5 criteria 8.2.5 Meeting adjourned 8.3 Track III PMA/Short Haul Copper/Optic Meeting ************************************************* Minutes taken by Vince Melendy of Methode Electronics. 8.3.1 Jonathan Thatcher called the meeting to order at 6:30 PM on Tuesday night, 11/12/96 8.3.2 Presentations were split into groups: 8.3.2.1 10 Bit SERDES chip Specifications 8.3.2.2 Short Haul Copper Physical Layer 8.3.2.3 Optical Physical Layer 8.3.3 The following presentations were given: 8.3.3.1 10 bit Specifications by Jonathan Thatcher for Bob Rummer 8.3.3.2 Serial Gigabit Ethernet Transmission over Twinax by Haluk Aytac. He concluded that internal equalization within the SERDES may offer simple, cost effective operation at 27 m specification. 8.3.3.3 Introducing the GigaBlaze G10 Serialink Core by Karl Nakamura for Sanjay Desal. This was presented to introduce ASIC system on a chip designs. 8.3.3.4 Bhavesh Patel gave a presentation on Short Haul Copper Issues and NEXT Measurements. His summary was to specify only one connector the HSSDC and NEXT is not an issue. 8.3.3.5 Ed Grivna presented 1000BASE-CX Proposal. He discussed a proposed specification for the copper medium. He suggested the use of Twinax cable, the HSSDC connector, and use cable crossovers. 8.3.3.5.1 Jonathan Thatcher would like to have a motion to remove the DB-9 product from the proposed standard and replace it with the HSSDC connector. He will request this at Wednesday's meeting. 8.3.3.5.2 It was requested that AMP give a letter making any patents available to anyone as per the IEEE standard on patents. 8.3.4 Jonathan Thatcher started the Optic presentations: 8.3.4.1 Schelto van Doorn gave an added presentation for the Methodologies for Jitter Specifications (MJS). He described the work the MJS group was performing. Schelto described the points where jitter would be measured. 8.3.4.1.1 The next Jitter meeting will be in Bloomington, MN on December 6 at 8 AM. The following will be in January 9 and 10, 1997 in Colorado Springs. 8.3.4.2 Del Hanson gave a presentation on the Review of 1300 nm & 850 nm Optical PMD Specifications for IEEE 802.3z Gb/s Ethernet. He recommended: 8.3.4.2.1 Use Fibre Channel Transmitter eye template for all cases. 8.3.4.2.2 Reduce 1300 nm source rms spectral width to 4 nm. 8.3.4.2.3 Maintain the 770 -860 nm source rms spectral width of 4 nm for CD lasers & future lower current threshold VCSELs 8.3.4.2.4 Use 0.45 ns source 10-90% response times to achieve: 8.3.4.2.4.1 230 m 62 MMF with lower cost 770-860 nm transceivers 8.3.4.2.4.2 850 m 62 MMF with length with 1300 nm transceivers 8.3.4.2.5 Define link serial jitter vs response time allocations following the FC jitter study group methodology 8.3.4.3 David Cunningham gave a presentation on Review of Hewlett Packard Proposal Long Wavelength Laser Based Fiber Optic Links. A discussion ensued on the Modal Noise measurements and the presented penalties. This meeting was adjourned at 9:10 PM and will reconvene at 8:30 AM on Wednesday morning. The meeting was convened at 8:30 AM Wednesday, 11/13/96, by Jonathan Thatcher. He made several Administration announcements. 8.3.5 The Optic presentations continued: 8.3.5.1 Vince Melendy made a presentation on Transceiver Specifications. Vince presented questions as to why deviate from the Fibre Channel Specifications and create a higher cost Gigabit Ethernet Specific module. 8.3.5.1.1 He concluded that the specifications should be consistent, not create a Gigabit Ethernet Specific product, and don't recreate a product. go back to the Fibre Channel Optic Specified products that will give low cost solutions to meet the goals of the Task Force. 8.3.5.2 Schelto van Doorn gave a presentation on Support for 1300 nm solution. He presented specifications for the Siemens proposal for the 1300 nm product. He concluded to use the single mode product now and for multimode to use a standard single mode module with a hybrid jumper. Next year use the single mode product with no restriction and a redesigned module with a standard jumper. 8.3.5.2.1 Discussion ensued regarding the VCSEL and edge emitting comparisons. 8.3.5.3 Bill Reysen gave a presentation on Gigabit Ethernet PMD. He gave the AMP view point of the specification. AMP can meet the proposed specifications but these may not be the optimum specification. 8.3.5.3.1 He recommended to continue with the work and define the models that you are using. 8.3.5.4 Paul Kolesar gave a presentation on the Recommended Changes to Optical PMD Proposal by Corning and Lucent. 8.3.5.4.1 He reviewed the proposed specification in detail. 8.3.5.4.2 He would like to be part of the work being done on the west coast with meetings every 2 weeks. This is an impossible travel schedule for the east coast companies, but Lucent and Corning want participate in the work. 8.3.5.5 Jonathan Thatcher presented recommended changes to the PMD specifications. 8.3.5.5.1 He made a proposal offering technical changes to the current optical proposals. 8.3.5.5.2 He would like to work later in the meeting to create some motions for the afternoon meeting. 8.3.5.6 Issues and Recommendations was the topic of Jonathan Thatcher's next presentation. He discussed distance limits due to noise penalties, Longwave Budget Optimization, and Laser Safety Limits 8.3.5.6.1 He suggested that the specifications are specifying HP products and as it stands the IBM products will not meet the specification. 8.3.5.7 David Cunningham gave a presentation on Long Wavelength Laser MMF Links: 50 MMF results. 8.3.5.7.1 He presented data to prove that the long wavelength laser & MMF can form a robust link. 8.3.5.7.2 He concluded that the above is true. 8.3.5.7.3 The test procedure for Modal noise has not been verified and that this test procedure does not reveal all the module failures. Discussion ensued regarding the testing of the Modal Noise. 8.3.5.8 David Cunningham gave another presentation on Chromatic Dispersion Limited Link Lengths for SWL and LWL Fiber Systems. 8.3.5.8.1 He recommended: 8.3.5.8.1.1 MPN must be taken into account in specifications 8.3.5.8.1.2 LWL maximum RMS width of 4 nm for 3 km SMF links 8.3.5.8.1.3 SWL maximum RMS width < 2 nm for 500 m links. 8.3.5.8.2 A discussion of the data took place for the rest of David's presentation time. 8.3.5.9 David Cunningham gave another presentation on Restrictive Mode Launch results. 8.3.5.9.1 David summarized: Using mode coupling theory for near square law fibers he showed: 8.3.5.9.1.1 Bandwidth enhancement due to RML is very sensitive to category of launch, this will make RML difficult to specify, 8.3.5.9.1.2 Bandwidth with SM transceiver launch into 62MMF is greater than or equal to OFL modal bandwidth of 62MMF 8.3.5.9.1.3 His recommendation is that the OFL bandwidth be used for all MMF IEEE 802.3z specifications until the TIA FO 2-2 completes its work. 8.3.5.9.2 There was discussion on the method in taking and theorizing the data. He has only done this on Long wavelength lasers. 8.3.5.10 Jeff Warren presented some data on 1300 nm modal noise. 8.3.5.10.1 His recommended to specify the launch conditions or postpone acceptance of 1300 nm on 62.5 until further study is completed. 8.3.5.11 Tad Szostak presented an Update on the Small Form Factor Optical Interconnect System. 8.3.5.11.1 This was an update to the small form factor interconnect system as proposed by 3M to the Fibre Channel Committee in October, 1996. 8.3.5.11.2 The Fibre Channel Committee is scheduled to make a formal decision on a future connection system at their February, 1997 Plenary. Schelto is asking the Chair of the X3T11 Committee how to proceed with the decision and will make no comment on when a decision is to be completed. 8.3.5.11.3 Discussion ensued on the selection of connectors. 8.3.6 Presentations ended at 11:35 AM 8.3.7 Jonathan Thatcher summarized so me of the presentations. The optic vendors have agreed that the link length goals can be met. However there is many TBDs that need to be put in the document. 8.3.8 Straw poll on the 10 bit specification was requested by Jonathan to adopt this specification and put it in the draft. The straw poll showed that it should be forwarded, about a dozen for and non opposed. 8.3.8.1 A question was asked if there are any copyrights on any of the X3T11 material. 8.3.8.2 A group will meet to create TBDs for the specification this morning. 8.3.9 Straw poll on the copper section was requested by Jonathan to adopt this specification and put it in the draft. The straw poll showed that it should be forwarded, about a dozen for and non opposed. 8.3.9.1 A group will meet to create TBDs for the specification this morning. 8.3.10 Howard Johnson discussed the agenda of the afternoon meeting. 8.3.11 Straw poll on the optic section was requested by Howard Johnson to ask the following persons to please make a joint motion to 802.3 for something to go into the 1st draft: Jonathan Thatcher Ali Ghiasi John Bowerman Bob Musk Steve Swanson Bill Reysen Paul Kolesar M. Nowell Vince Melendy David Cunningham Stan Swirhun Tad Szostak Del Hanson Schelto van Doorn The motion was to go and fulfill the above made by H. Johnson and seconded by Bob Fink. The vote was Yes -46, No -0, Abstained -11. 8.3.11.1 Discussion was on the changes necessary in the document. The TBDs should be placed since several vendors do not agree on the correct specifications. 8.3.11.2 Steve Swanson of Corning wants to amend his proposal to the document to go forward. 8.3.12 The meeting was adjourned at 12:05 PM. 8.4 Track IV User Requirements ****************************** The meeting was Chaired by Howard Frazier. Started at 1:10pm on Wednesday, November 13, 1996. Andy Luque kindly agreed to take minutes until Dave Fifield re-appeared (he was at the 100BASE-T Maintenance meeting). 8.4.1 Fiber Optic Cabling Survey ******************************** By Chris Di Minico - Different tack than Compaq's survey - Results of the survey were presented - BICSI distributed survey to 2000 users - There is very little 50um fiber between buildings - International organization, 95% US Chair asked if Alan Flatman could present his survey data. There were no objections. 8.4.2 Fiber Cabling Survey ************************** By Alan Flatman - will survey Europe - next 2 months - UK survey by FIA, a fiber optics supplier - installed building backbone - Oct 95 to Oct 96 - Total 1,200 Km, 79% < 200m, 47% > 400m (?) - 62.5um fiber predominantly - Only Japan and South Africa use 50um fiber 8.4.3 A User's View of Gigabit Ethernet *************************************** By Bob Fink of Lawrence Berkeley Labs. - Users elected not using ATM - want fiber - Will wait for copper - Large user sites - demand for product - Reasonable to get compromise 8.4.4 Gigabit Survey - Results, Analysis, Proposals *************************************************** By Rich Gardner - US only - Results based (on) 366 (replies?) - Weighted results - Survey results presented 8.5 Review of Work ****************** At this point in the proceedings the Moderators of Tracks II and III were asked to give an overview of their work to the assembled 802.3z Task Force. 8.5.1 Track II - George Eisler ****************************** 1. Reviewed a number of technical proposals 2. There is some concern that Long Haul Copper PHY work could delay the 802.3z standard 3. Discussed the formation of objectives for Long Haul Copper PHY 4. There were 8 objectives 5. Draft for a PAR for Long Haul Copper PHY was considered Long Haul Copper PHY Objectives ******************************* 1. Comply with the GMII specification 2. Full duplex and half duplex operation 3. FCC class A, hope for class B 4. Operate over 100m of 4 pair Cat5 cable as per 11801/568 5. BER 10E-10 6. Auto-Negotiation supported 7. Identify the appropriate susceptibility specification 8. Objective 802.3z Nov 13, '96 - 802.3z PAR to be considered at March meeting - Question on the PAR to the executive. Is the PAR to be created by the Task Force? - Question on the Objectives. Chop 3. and replace it with 7. Have one emission and one susceptibility spec. (Howard Frazier disagreed with this) - Change 2. - Full duplex line transmission which supports full duplex and half duplex. At this point in the proceedings, Dave Fifield took over the keeping of minutes again. 8.5.2 Track III - Jonathan Thatcher *********************************** Jonathan gave a status report of the Short Haul/Fiber PMD and the PMA. - A straw poll was taken which showed there was significant interest in forwarding the "spec." to 802.3z as a motion. - Set-up and hold timing - these specifications are what we *all* need to look at really closely. The group needs feedback asap. They will put a process together to establish this later. - Short Haul Copper looks very do-able. The group has written up the 10B specification in IEEE'se - Optical PMD - This is the first time that the numbers have really been dug deeply into. There is general consensus that they meet the various objectives of 802.3z. A good deal of work on the test document is still required. A new optical connector may appear. Fibre Channel will select this connector soon, then we'll probably adopt it too. Q. For the 8B/10B spec. re-write, is it a replacement of in addition to Fibre Channel? A. The 10B spec. will continue to be the Fibre Channel specification. We intend to include our document in 802.3z. There are differences, but they are not large. It will be better to have our own standard all in one place. Q. OK, but what about real products, can they be made to support both the Fibre Channel spec. and the new 802.3z spec? A. That is our intention, but there's no guarantee that a product made for one spec. will automatically meet the other. Vendors will have to ensure this themselves. Jonathan then "did not tell a joke". 9. Organization of Task Force ***************************** The Chair presented a proposed list of Sub Task Forces based on Track I, II and III. Long Haul Copper had been inadvertently left off the list so was duly added to the Track II Sub-Task Force. There seemed to be general consensus that having the Sub-Task Forces split along the same lines as the Tracks (and the proposed organization of the standard) was the best way to proceed. 9.1 Motion #1 ************* "To establish the Sub-Task Forces as presented and the Track Moderators as the Sub-Task Force Chair/Editor in each case." Note that this motion was not written up on the overhead but was written verbatim in the minute secretary's notes directly. Moved: Bob Fink Seconded: Alan Flatman Chair - is there anyone else who'd like to run for these positions? No one did. Q. What are the voting rules? A. If you're in the room and you feel qualified, then you can vote. Q. Is there a rationale for Optical, PMA and Short Haul Copper in one group? A. Yes, they all use the 8B/10B interface specification. Q. What was the rationale for MAC and Repeater being in one group (it wasn't in 100BASE-T)? A. The MAC effort will be low and will have implications in the repeater section, so I put them together. Q. Do we need a Sub-Task Force for a Management Section? A. We will do. Do you want to volunteer? Thanks for bringing it up though. Q. Do we need a permanent (standing) secretary? A. No. We don't want to put that onerous task on just one person all the time. Voting on Motion #1: Passed by acclamation. The Chair then stated that we need to have the rest of the afternoon for other motions. Each will require 75% to pass (since they're technical). We don't want conflicting motions so a "second" motion on a topic must be written to supersede the first. We need to be very clear about what will be in our first draft. Dr. Howard Johnson then proposed the following motion: 9.2 Motion #2 ************* "Instruct the chair and editor(s) of 802.3z to generate a first draft for review in January 1997, based on the following presentations, plus any other presentations or amendments as may be approved by 802.3z for use "as the basis of the first draft". 9/96 Frazier Review and Update of Carrier Extension 9/96 Haddock CSMA/CD Bit Budget 9/96 Johnson PCS-Update to Protocol Proposal 9/96 Taborek Gigabit Ethernet Serial Line Codes 9/96 Hanson et al Optics 11/96 Grow GMII AND (see page 2) Page 2: Minimal specification of asymmetric flow control as defined in: 11/96 Bunch Asymmetric Flow Control to permit operation of buffered distributor as presented in: 11/96 Daines Full Duplex Repeater Update" Moved: Dr. Howard Johnson Seconded: Bob Fink Discussion: Q. If we agree with 95% of the content of this work but disagree with 5%, rather than nit-pick *now*, can we change it later? A. The reply essentially was "The first draft will appear based only on the motion(s), subsequent changes may be made of course" A request was made for anything we vote into the first draft standard to please make sure there are additional copies available by tomorrow for those who were at other Track's meetings. Paul Woodruff - We've not really seen enough work in this group to decide if asymmetric flow control is appropriate. I've signed up to do some of the work myself. If we find we need asymmetric flow control it would be easy to add it later. Therefore I propose a friendly amendment that you: "Remove page 2 and the reference to it on page 1". Chair to Mover - Do you accept that as a friendly amendment? Mover - No, not friendly. Chair - Therefore we take it as an unfriendly amendment: Moved: Paul Woodruff Seconded: Andy Luque Discussion: Both the mover and seconder spoke to say that this was not a big deal and can easily be added later if required. Mark - This is just the "basis" for the draft, it isn't concrete, we should put in everything we'd like to possibly see. Howie - Paul's concern is for complex switching architectures....Howie emphasized that all this does is permit a buffered distributor as presented. Bill Bunch - The performance will be basically the same for switches and buffered distributors. Bernard - Agreed, we could add it in later, but I'd like it in now so we can get started on the work. Gadi - Not like having a repeater....(sorry, I missed the rest of the question here, Gadi didn't use the microphone). Bob Fink - We need to keep it in. If there's trouble with it later, we can take it out, but it's good to put it in now. Paul Woodruff - Presentations have shown that you can tune a network to not need 802.3x.....don't believe we've done any work that proves that only buffered distributors will want/need to use asymmetric flow control. John Payne - Asymmetric flow control is optional and as such you don't have to use it. Scott - Looking at the paper (Bill Bunch's), if this proposal succeeds then technical stuff like Auto-Negotiation will be included but the (useful) commentary not; am I right? Howard - Yes, only the technical stuff will be included. I see your point about the other useful work, it's a legitimate question, but right now it's just the concept that we're talking about (not the details). Howie - The intention was to call out just the minimum amount of stuff from Bill's presentation to allow buffered distributors. Voting on the unfriendly amendment: Y: 35 N: 57 A: 28 (Technical) Amendment fails. Back on the main motion #2: John Payne called the question. There was objection to calling the question, so a vote on calling the question was taken: For calling the question: 47 Against calling the question: 37 Therefore the question was called. No further discussion was allowed. The Chair read the main motion again. Voting on Motion #2: Y: 117 N: 22 A: 13 (Technical) Motion #2 Passes. There was a spontaneous round of applause. The Chair commented that this was probably the largest YES vote this group has ever seen. At this point the Chair took the names of other motion proposers in order to try to group together similar motions and ensure the smooth flow of the meeting. The following people said they'd be proposing the following number of motions: Eisler 1 Bowerman 1 Thatcher 2 Lahat 1 Muller 1 Haddock 2 Chen 1 Salzman 3 Hsiaw 1 Taborek 1 Augusta 1 Total = 15 motions. It was suggested that speakers use the main microphone and form a physical speaker's queue at the mic. The Chair said he would ensure fairness for the speakers. 9.3 Motion #3 ************* "Move that 802.3z adopt the PCS simplification proposals made by Mike S. and Igor ZHOVNIROVSKY into the 802.3z draft standard" Moved: Gadi Lahat Seconded: Mike Salzman Discussion: Mike S. - This will expedite and simplify the standard. Unknown - Disagree. This will prolong the process since it's all new work. Bill Bunch - Auto-Negotiation using packets has always failed in the past. Rich Taborek - We don't need a Jam character, it complicates a simple situations. Only simple 10BASE-T is possible with this mythical endec- less repeater. My proposal doesn't include any "architectures" (this one does). Scott - I'm against this motion, much of the material is new and untested. Voting on Motion #3: Y: 8 N: 50 A: 53 (Technical) Motion #3 Fails. 9.4 Motion #4 ************* "Use "as the basis of the first draft": 11/96 Haddock Bit Budget superseding earlier presentations with which it may conflict." Moved: Stephen Haddock Seconded: Bob Fink A friendly amendment to add "with adaptations for 32 bit MAC" was proposed by Unknown and accepted by the mover and seconder, so the motion reads: "Use "as the basis of the first draft": 11/96 Haddock Bit Budget superseding earlier presentations with which it may conflict with adaptations for 32 bit MAC" Voting on Motion #4 as amended: Y: 108 N: 0 A: 11 (Technical) Motion #4 Passes. 9.5 Motion #5 ************* "Include Packet Bursting in First Draft of P802.3z based on the contents of: Packet Bursting Proposal Kalkunte et al 11/96 Pascal for Packet Bursting Molle 11/96 Impact of Packet Bursting on GMII and PCS Frazier 11/96" Moved: Stephen Haddock Seconded: Pat Thaler Discussion: Stephen H. - This set of presentations taken as a group form the whole Packet Bursting section. I originally proposed packet packing. This proposal solves the statistics/collision problems of packet packing. I think this addresses all the issues that were originally raised. Pat T. - What he said! Q. Does this supersede carrier extension? A. No, the two, carrier extension and packet bursting, go together (packet bursting requires carrier extension to exist). Q. Do we *have* to implement it if it's adopted? A. A receiver would *have* to understand this, but a transmitter does not have to. Q. Is this only for half-duplex? A. Yes. Voting on Motion #5: Y: 78 N: 13 A:31 (Technical) Motion #5 Passes. 9.6 Motion #6 ************* "Allow the Tx PCS to reduce the preamble by one byte in the event that the MAC asserts tx_en on an odd byte boundary." Moved: Linda Chen Seconded: Rich Taborek Discussion: Rich T. - Either you do this or you don't. I think this is the better way to go. Gadi L. - This was option 1, right? The start of frame delimiter will appear misaligned on 16 bit implementations. Linda C. - I don't want to push 16 bit alignment down to the PCS. Scott - If you delay one frame and not the next, you've shrunk the IPG which is not good. I think this proposal is good. Gadi - (asking Scott) When you refer to IPG shrinkage, do you mean at the GMII interface? Scott - Yes Gadi - Expressed his opinion about the IPG timing of the bits on the wire. Scott - I've only looked at the timing of the bits at the GMII, so I can't comment on the timing of the bits on the wire. Linda - In half-duplex, the PHY could use the carrier detect signal to flow control the transmit MAC, preventing IPG shrinkage dur to (PHY) delayed frames. Under sustained worst-case alignment this would deliver 996Mb/s. Scott - Agreed with Linda that this was possible in the half-duplex case. In the full duplex case, there is no mechanism for the PHY to flow control the MAC, so, operating at line rate, if one frame is delayed by the PHY then the IPG to the preceeding frame is increased while the IPG to the next frame is decreased. Steve H. - We want *byte* alignment. It's (IPG shrinkage) a fairness question. The other solution would be unfair. Voting on Motion #6: Y: 78 N: 4 A: 31 (Technical) Motion #6 Passes. At this point in the proceedings Mike Salzman withdrew his name from the list of motion makers for which he received substantial applause. 9.7 Motion #7 ************* "Acknowledge the 802.3x standard. Extend 802.3x flow control to be more efficient and achieve end-to-end flow control objective. Call for additional work to investigate Layering Credit Based Flow Control on top of 802.3x for gigabit flow control" Moved: Henry Hsiaw Seconded: Igor Zhounirovsky Discussion: Cal Nelson - .3x is not intended as a solution for end to end flow control or steady state congestion. For large switching systems this is a good way to go. Gadi L. - Q. Both mechanisms are link based (I think he meant frame based) mechanisms, why do you see this as "better"? Henry H. - Current .3x is more appropriate for the end user but is not useful for large switched systems. Therefore, it won't provide end to end flow control like a credit based scheme would. Cal N. - You won't *have* to use it in small systems. Shimon M. - Where do you propose that this work be done; .3x or here? Henry H. - I believe it can be done in .3z and added as an annex to .3x later. Unknown - Therefore, we don't need a motion to do this work, do we? Henry H. - I'd like to see a sub-sub-work group (I think he meant Sub- Sub-Task Force) present this at the next meeting. Bob Grow - I doubt that it would be ready in time, and we really don't want to get bound up in another flow control mechanism. Andy Luque - Is this going to be restricted to .3z or made general for all, as a .3x addendum? Henry H. - I repeat my previous answer on this one...work in .3z, then append to .3x Andy L. - It's not a goal of ours to do general flow control work in .3z Voting on Motion #7: Y: 18 N: 56 A: 40 (Technical) Motion #7 Fails. Note that the 'Y' vote was taken twice due to some remarks about raising hands higher by the Chair in between the 'Y' and 'N' counts first time round. He did this to be fair - the 'Y' vote went up by 1 (from 17 to 18). 9.8 Motion #8 ************* "Use "as the basis of the first draft": Date Author Title **** ****** ***** 11/96 Taborek 8B/10B PCS Update superseding earlier presentations in which there may be conflict." Moved: Rich Taborek Seconded: Scott Mason Discussion: Rich T. - This eliminates the F code and other changes. Scott - I agree with the changes Rich has done. He's done an excellent job. This version is the 'end goal' not the Reprint Book stuff. Voting on Motion #8: Y: 111 N: 1 A: 6 (Technical) Motion #8 Passes. 9.9 Motion #9 ************* "The 802.3z task force request that The 802.3 Working Group authorizes the 802.3z to produce a PAR with supporting documentation, to facilitate the establishment of a separate task force to conduct the standards work on the long haul copper PHY and that the 802.3z task force forward this PAR and supporting documentation to the IEEE802 Executive Committee at least 30 days in advance of the March 1997 802 meeting for consideration at the March 1997 IEEE Standards Board Meeting." Moved: George Eisler Seconded: Colin Mick Andy Luque asked Howard Frazier if this was the same process that we took for 100BASE-T. It was. No other discussion. Voting on Motion #9: Y: 109 N: 1 A: 13 (Technical) Motion #9 Passes. 9.10 Motion #10 *************** "Use as the basis for 1st draft the "Joint Proposal, Sept.1996 (Blue Book)" as modified on 11/13/96 by the group listed below as the base draft for the optical PMD. To supersede any previous presentations in which there may be conflict. Jonathan Thatcher John Bowerman Steve Swanson Paul Kolesar Vince Melendy Stan Swirhun Tad Szostak Del Hanson Shelto Van Doorn Ali Ghiasi Bob Musk Bill Reysen Mark Nowell David Cunningham Ed Cornejo" Moved: John Bowerman Seconded: Shelto Van Doorn Discussion: John B. - This work reconciles a lot of work done and is consistent with the goals. Shelto - This is the consensus basis for a good working document. Howie - I observed good discussion in this Track. Several proposals were made, any one of which would work. At the end of the session, I called for these people to get together and agree on the way forward. Bob G. - I propose a friendly amendment to change the word "Blue" to "Reprint". This friendly amendment was accepted by the mover and seconder, so the motion reads: "Use as the basis for 1st draft the "Joint Proposal, Sept.1996 (Reprint Book)" as modified on 11/13/96 by the group listed below as the base draft for the optical PMD. To supersede any previous presentations in which there may be conflict. Jonathan Thatcher John Bowerman Steve Swanson Paul Kolesar Vince Melendy Stan Swirhun Tad Szostak Del Hanson Shelto Van Doorn Ali Ghiasi Bob Musk Bill Reysen Mark Nowell David Cunningham Ed Cornejo" More discussion: Jonathan T. - This is a good basis for the first draft, there is general agreement on it. This is critical for future work. Voting on Motion #10 as amended: Y: 95 N: 0 A: 15 (Technical) Motion #10 Passes. 9.11 Motion #11 *************** "Use "as the basis of the first draft": Date Author Title **** ****** ***** 11/12/96 Ed Grivna Short Haul Copper Proposal with the following changes: Maximum risetime => 327ps Link length => TBD Receive amplitude => TBD Connector pin-out table => convert to crossover only as discussed at today's Track III meeting" Moved: Edward Grivna Seconded: Richard Dugan There was no discussion. Voting on Motion #11: Y: 66 N: 0 A: 30 (Technical) Motion #11 Passes. 9.12 Motion #12 *************** "Use as "the basis of the first draft" with the following changes: For transmit interface timing min tsetup => 2ns min thold => 1ns as discussed at today's Track III mtg. Date Author Title **** ****** ***** 11/13/96 Bob Rumer 10B SERDES for GE" Moved: Michael Yam Seconded: Haluk Aytac There was no discussion. Voting on Motion #12: Y: 51 N: 0 A: 42 (Technical) Motion #12 Passes. 9.13 Motion #13 *************** "That 802.3z include CAT-5 UTP as an alternative short haul jumper technology for the initial draft standard based on the document "Gigabit Ethernet UTP-5 Phy" Nov, 1996 by PMC-Sierra." Moved: Stephen Augusta Seconded: Iain Verigin Discussion: Bernard - It's a good idea to allow other applications. Unknown - What about FCC (interference) problems outside the box? Stephen - There should be no problems. Gadi - I'd like to propose a friendly amendment to add "4 pair" in front of "CAT-5..." This friendly amendment was accepted by the mover and seconder, so the motion now reads: "That 802.3z include 4 pair CAT-5 UTP as an alternative short haul jumper technology for the initial draft standard based on the document "Gigabit Ethernet UTP-5 Phy" Nov, 1996 by PMC-Sierra." More discussion: Howard - Do you have a reference document? Stephen - Yes, it's the "Gigabit Ethernet UTP-5 Phy" Nov, 1996 by PMC Sierra. Geoff T. - Where does this work belong, short haul or long haul copper? Mark - This work does have a datacenter application either now or very soon. Alan - Wasn't this work defeated at the Coeur D'Alene meeting? The minutes of that meeting were checked. The Chair read the relevant motion "...that clause 39 of draft (long haul) be split into 2 clauses...". He told us that this motion had failed, 18 to 35. George - This is a new line coding scheme, it doesn't use 8B/10B or anything like the long haul copper may use. Gadi - Do we have the bits the Auto-Negotiation Base Register to support this? Howard - I don't think so. This would have to be next page stuff. Rich - I'm unclear about what "short" means here? Iain - We think it means 25m, 30m possibly. Gadi - The logic for this proposal is that they can use current Cat5 installed wire. The problem is that a lot of installations will have much more than 25 or 30m of wire installed. This will lead to big problems. I'd prefer to have a new cable for short haul links. Unknown - This uses already existing technology, cables and connectors. I don't want to have new ones. Bob G. - This is deja vu all over again! It happened in ATM etc... This is proliPHYration. We've got enough PHYs already, we don't need more. Voting on Motion #13 as amended: Y: 36 N:61 A: 25 (Technical) Motion #13 Fails. 9.14 Motion #14 *************** "Instruct the editors of the first and subsequent drafts to produce the documents in Framemaker format." Moved: Shimon Muller Seconded: Bill Quackenbush Discussion: Shimon - The IEEE requires the document in Framemaker, so why not just do it straight in that. Voting on Motion #14: (Procedural) Passed by acclamation. 9.15 Motion #15 *************** "Use "as the basis of the first draft": Date Author Title **** ****** ***** 11/12/96 E.Grivna Short Haul Copper Proposal As previously modified with the addition of the HSSDC, with the assumption that IEC efforts presently underway are complete prior to release of 802.3z" Moved: Ed Grivna Seconded: Richard Dugan Discussion: Unknown - The HSSDC connector is expected to have its IEC number in March '97. David D. - The patent status is that there are none, and none are pending. Howie - We need to either have a reference to a connector or the whole specification of it in the standard. It's not appropriate to jam a new connector into our standard in advance of IEC. This could lead easily to "connector wars" with many other vendors wanting their connector added too. Steve H. - I'm for the motion, work could go ahead, why wait for the IEC. Howard - Tracking the specification for a new connector is a nightmare. Changing part numbers/specifications causes grief to our standards work. Geoff T. - We must wait till a connector stabilizes and becomes an IEC standard. We should hesitate in making a hasty decision here. Geoff Thompson then offered a friendly amendment to make this connector a "candidate". Richard Dugan said he'd withdraw his support as seconder if the wording stayed the same. Ed Grivna offered to reword the motion to make this connector an "addition". Richard Dugan said this would be acceptable and he'd still second it, since the connector is a very good one. Ed D. - The old DB9 is only specified to 3MHz, however, people do make versions that work for Gigabit frequencies. These connectors are not a part of any specified standard. The HSSDC connector will be a standard. Pat T. - (started to offer a friendly amendment) Howard - There is another, better motion than this, waiting in the wings. At this point, Ed Grivna and Richard Dugan withdrew Motion #15. 9.16 Motion #16 *************** "1) 802.3z will not consider connector issues at this time, nor will any connector which is not currently an ISO/IEC standard (or at least draft std), or which is not included in the FC-PH, be included in the first draft of 802.3z. 2) 802.3z will monitor the progress of the connector discussions in X3T11. 3) 802.3z will entertain connector proposals at the March, 1997 meeting. 4) 802.3z will make a final decision on the connector specifications for all media types prior to issuing a draft for working group ballot." Moved: Howie Johnson Seconded: Shimon Muller Discussion: Ed G. - I support this motion. Alan - I offer a friendly amendment to strike "ISO" from the motion. This friendly amendment was accepted by the mover and seconder, so the motion reads: "1) 802.3z will not consider connector issues at this time, nor will any connector which is not currently an IEC standard (or at least draft std), or which is not included in the FC-PH, be included in the first draft of 802.3z. 2) 802.3z will monitor the progress of the connector discussions in X3T11. 3) 802.3z will entertain connector proposals at the March, 1997 meeting. 4) 802.3z will make a final decision on the connector specifications for all media types prior to issuing a draft for working group ballot." More discussion: Jonathan T. - I recommend this, it gives freedom to the working group (Sub-Task Force) to get stuff done. Voting on Motion #16 as amended: Y: 106 N: 0 A: 2 (Technical) Motion #16 Passes. 10. AOB ******* None 11. Plans For Next Meeting ************************** A proposal was made to hold the next meeting on Monday, Tuesday and Wednesday, January 27-29, 1997 in San Diego. Exact hotel details are yet to be arranged but it is likely to be in the Mission Bay area. This meeting will be sponsored by XLNT Designs Inc. (Bob Grow). Proposal passed by acclamation. 12. Previous Minutes ******************** The Chair called for any objections to approving the minutes of the September meeting (Coeur D'Alene). There were none. A motion to approve the minutes was entertained. Moved: Bob Fink Seconded: Pat Thaler Voting: Y: 68 N: 1 A:3 (Procedural) Motion Passes. The Chair asked who it was that voted 'NO'. Gadi Lahat said that he did not agree with some of the text in the minutes. The Chair admonished Gadi, saying that if he had real objections he should have spoken up and offered changes as required. This would keep things proper. 13. Adjourn *********** The meeting was adjourned at about 6pm on Wednesday, November 13, 1996.