THIS TEXT HAS NOT YET BEEN REVIEWED FOR TECHNICAL OR EDITORIAL ACCURACY. Minutes of: P802.3z Gigabit Ethernet Task Force 27 - 29 Jan 1997 Hyatt Islandia San Diego, CA, USA Howard Frazier, Chair === Disclaimer: At times, the discussion moved very quickly. These minutes paraphrase each speaker. Do not judge the speaker nor the secretary by the apparent tone or connotation of paraphrased attributions. These minutes are provided on a best-effort basis. The Task Force expresses thanks to Scott Mason, John Bowerman, and Colin Mick for recording these minutes, and recognizes that they cannot be held responsible for the contents. These minutes are not approved and unofficial unless approved by P802.3z, at which time they become the property and responsibility of that group. === Monday's session and Wednesday's PM session were held before the entire P802.3z task force. Tuesday's session and Wednesday's AM session were held separately before three groups: Track I (system, MAC, 1000 Base-X PCS, 1000 Base-X PMA, repeater), Track II (UTP PHY), and Track III (1000 Base- X PMD). === Monday 27 January 1997 ================================== | Agenda and General Information | ================================== Presented by Howard Frazier. Introductions ============= Approx 105 persons were in attendance at 8:45 Monday morning. Howard asked for a straw poll on how many persons were "new". He defined "new" as not having recently attended 802.3z sessions. Approx 10 persons identified themselves as new. Select recording secretary ========================== Scott Mason (Plaintree Systems, Ottawa, Canada smason@plaintree.com) was elected as recording secretary for the task force and for track I. Track II and track III sub- chairs were tasked to identify recording secretaries at the beginning of their breakout sessions. P802.3z status report ===================== See Howard's presentation. Standard's development timeline =============================== See Howard's presentation. Email reflector and ftp/web sites ================================= See Howard's presentation. Also: A survey was included in the attendance books that enabled persons to identify themselves as willing to receive documents distributed exclusively via the Internet. Howard commented that he may also use these results as an indication of interest in a web-based comment process. Review HSSG objectives and PAR ============================== See Howard's presentation. Distribution of documents ========================= Copies of Draft D1 were distributed to those persons needing them. Call for patents ================ Howard conducted a call for patents and indicated that this would be repeated in every meeting going forward. He described the process and policy, illustrated with example inquiry and response letters. Please see Howard for details. Steve Swanson of Corning expressed his firm's concern with a process that uses a call for patents in the meeting. He raised a concern that not speaking up at the meeting may imply that a person has no applicable patents or agrees to comply with the IEEE patent release. He read a prepared statement that said: "Corning has numerous patents which relate to optical fiber and components used in connection with optical communications systems. One or more of those patents may relate to the subject matter of standards which may be proposed by this Group. In preparation for this meeting, I have not reviewed all of Corning's U.S. patents to determine if there are one or more which are specifically related to matters currently being considered by this Group. It is Corning's position that such a review would be unduly burdensome and necessarily would involve speculation. When a standard is to be voted on by the membership, Corning will, in response to a written inquiry from the Group, provide its views regarding any patents which it owns and which may be relevant to the proposed standard." Howard noted that a company can agree to license applicable patents without specifying which patents. Agenda ====== See Howard's presentation. Also: A request was made to add a 100 Base-T maintenance committee meeting to the agenda. The meeting was proposed in order to review the contents that are going out for maintenance ballot. It was agreed to accommodate this informally in the evening. (Secretary's note: I am not aware if such a meeting was held and, if so, have no minutes from such a meeting.) It was agreed to move the Track III presentation "TR41.8.1 Liaison Report, Chris Di Minico" to Track II at the request of the presenter. It was agreed to reprise the Track I presentation "GMII electrical specification, David Fifield" in Track III, in addition to Track I, at the request of Jonathan Thatcher. Moved and seconded to approve agenda. Voice vote: unanimous. ====================== | Review of Draft D1 | ====================== Introduction ============ Howie Johnson presented. Howie reviewed the FTP sites for draft D1 and for the selected presentations from Vancouver. Howie commented that ANSI copyright issues appear to be closed with a release letter from ANSI. This is to be confirmed. Howie reviewed the naming conventions used in draft D1 and proposed for the standard: "1000 Mb/s MAC" or "1000 Mb/s operation" is used as the top level. "1000 Base-X" is used to include the family of: - "1000 Base-LX", used for long wavelength (LWL) optics over single-mode fiber (SMF) or multi-mode fiber (MMF), - "1000 Base-SX", used for short wavelength (SWL) optics over MMF, and - "1000 Base-CX", used for short copper jumpers. All of these use 8b10b line coding. "1000 Base-T" is used for future CAT-5 UTP. Conventions =========== Secretaries note. Conventions used in these minutes: "C:" loosely translates to "comment". It refers to comments or questions from a person other than the presenter and directed to the presenter or to the group. In general, the name of the person is not provided. Where I interpreted an elected person other than the presenter to be speaking in their official capacity, I sometimes included a note as to the speaker. "A:" loosely translates to "answer". It refers to comments from the presenter. "GE" = gigabit ethernet. Draft D1 - Contents =================== Howie Johnson presented. A: Will be formatted to IEEE specs. Draft D1- Clause 01 =================== Howie Johnson presented. Figure 1: C: Add to footnote "*": AUI is not specified for 1000 Mb/s. C: Change GMII footnote "**" to use "***" notation. C: Change footnote "***" to use "****" notation. C: LLC layer also maps to OSI data link layer. C: Propagate corrections to figure 1 throughout all clauses. A: Current page number notation, for example 01.1, will be changed to become numbered sequentially throughout the document. Page 2: C: Line 39 - I understand the intent of "GMII is a board- level interface" but the phrase needs to be worded such that it is clear that this is not intended to be an exposed interface. C: Need to bring clause 34 references and definitions forward to clause 1. A: Editors need to identify new definitions. Page 3: C: Line 1 - The text "IBM-licensed" implies that the IBM license is valid. Not appropriate to take a stand or comment on the license. C: Somehow need to communicate how to license. A: IEEE patent letters. 802.3 will provide a list of patent letters on request. C: I believe that IBM has supplied patent letter. Draft D1 - Clause 02 ==================== Howie Johnson presented. No comments. Draft D1 - Clause 03 ==================== Howie Johnson presented. No comments. Draft D1 - Clause 04 ==================== Howie Johnson presented. A: This clause is based on revision 3.1, which is currently in sponsor ballot recirculation 802.3x. Page 2: C: Editors need to clarify and define for themselves use of the terms "frame", "packet", and "stream". All clauses should be updated for correct use and consistency. C: A diagram would help to clarify the meaning of these terms. C: May want to define an additional term for an extended frame - that is, a frame plus its extension, if any. C: Lines 12 - 16 should be re-worded to describe the uncoupling of slot time from the minimum frame size. C: Line 20 - "short frames" should be clarified. C: Line 39 - Is "bits" appropriate w.r.t. "extension bits"? A: Yes, the MAC is defined as bit serial. C: Line 50: "frame" should be "frame and its extension, if any," C: Throughout - "to the end of" is redundant in "append to the end of". Page 3: C: Line 1 - "send" should be "initiate". C: Line 2 - Replace "until a specified limit is reached ..." with a new description defining the maximum carrier event. C: Line 2 - What is the optimum maximum burst time? A: The current burst time-out is intended to prevent bulk file transfers from getting 2x bandwidth. C: The current burst time-out is trying to get fairness, as measured by close to the same number of bits transmit. C: Bulk transfers are not always using max length frames. The current burst time-out favours mixed frame sizes and frame sizes just less than the maximum. C: Line 5 - "frame" should be "frame and its extension, if any," C: Line 7 - Late collisions should terminate a burst. C: Issue - Should a station re-transmit on late collisions? Page 4: C: Line 1 - The definition given for the smallest valid frame is not true for the second and consecutive frame in a burst. C: Line 3 - "1000 Mb/s" should be "100 Mb/s". Howard Frazier presented. A: Some changes were made to the PASCAL since Vancouver. These include removal of the extension counter, addition of the physicalBit type, and (unspecified) bug fixes. C: Throughout PASCAL: "medium" in the comments is better expressed as "physical layer". The medium does not use multi- valued logic as defined by physicalBit type. Page 5: C: Line 43 - "packets" is not used correctly. C: Line 44 - Need a better term for "myBurst" that does not use "my". Page 6: A: The note at lines 51 through 54 is not related to gigabit. Page 7: A: Note that any variables related to bursting are only touched after testing burstMode. C: How to ensure that burstMode is only set for gigabit? Page 9: C: Line 30 - The burst timer is tested twice in txLinkMgmt and also in bitTransmitter. Some of these tests are redundant. Page 11: C: Line 2 - The name "BurstTimer" does not describe this function well. Name should include a verb to indicate its action. C: Line 2 - The type "bits" is not a declared type. A: This was changed from a real-time count to count bits. Page 12: C: Line 7 - bitTransmitter appends interframe fill of extension to a frame even if no other frame waiting to send. A: The MAC PASCAL cannot tell if there is another frame waiting to send. C: Implementations are allowed to avoid this, optionally, if desired. C: Add this allowance. C: Line 33 - extensionBit is also not sent during preamble. C: Line 38 - PhysicalSignalEncap is not checking for collisions during preamble. A: That is OK. (He then went on to waffle; he did not appear to reach consensus with himself). C: Line 49 - InterFrameSignalEncap does not check for collisions. These would be late collisions. A check needs to be added. Page 13: C: Describe how 10/100 implementations still comply. Page 14: A: Daggers are previous changes by layer management. A: Struck-out daggers are changes made by this editor where he believed that layer management should not have added daggers. A: Underlined daggers are changes made by this editor where he believed that layer management omitted daggers. Page 15: C: lengthOrTypeParam is not a boolean. A: Should be less than or equal to minTypeValue. C: Check if should be less than only, not less than or equal to. Page 16: C: Lines 17 and 31 - Check that the second assignment to receiveSucceeding is not unintentionally over-writing the first assignment. C: newBurst is used even if bursting is not used. An example is carrier extension. Carrier extension should be separated from bursting. Dependencies on newBurst should be examined and reduced. C: Line 48 - The "In burstMode" check should be deleted and the assignment statement should be unconditional. C: Line 48 - This assignment needs to be in the code portion of the PASCAL and not in the comment portion. Page 19: Results of discussion: For 10/100, extendSize should be set to 0, burstMode should be false (0), and burstLength should be not applicable. C: How are 10/100 receivers compliant with updated PASCAL? A: Could be just because they will never receive extend bits. Alternately, could gate with checks for extendSize > 0 in the PASCAL. Draft D1 - Clause 34 ==================== Howie Johnson presented. Page 1: C: Line 27 etc. - Update figure references; for example, figure 21-1. C: Line 33 - Change "from" to "beyond". Page 2: C: Add MAC control layer. Indicate that implementing the MAC control layer is optional. Propagate to other clauses. C: Ethernet may be trademark of Xerox. A: The Ethernet trademark has been relinquished by Xerox. C: Line 28 etc. - Correct "100Base-T". Editors should check for this common clone-and-own error, throughout. C: Line 33: SX clauses are 36 and 38, not 36 and 37. C: Line 33 - two MMF should be duplex MMF. C: Line 37 - Append "with a PCS that is unique" with reference to 1000 Base-T. C: Line 42 - Multiple repeaters should be one repeater. C: Line 42 - Strike "to provide maximum path length" in repeater description. C: Line 45 - Automatic Feature Configuration should be Link Configuration. A: What should 802.3z say about link configuration for 1000 Base-T? Page 3: C: Move to clause 1. A: Delete. Many don't apply to gigabit. Editors to build a new list for gigabit. Page 5: A: MMF should be SMF in reference to 10u fiber. C: Add "N" indicates normative and "I" indicates informative. Page 6: C: Line 1 - Strike "exposed" in reference to GMII. C: Line 3 - Change "These assumptions ..." to convey that the bit budget was based on these. C: Move section 34.8 to clause 35. C: Various - TX_CLK should be GTX_CLK. C: Line 13 - MII should be GMII. C: Should change from min and max in bytes to bit times. C: A diagram should be added to illustrate these timing points. -- Lunch -- Draft D1 - Clause 35 ==================== Bob Grow presented. Page 1: A: Started with clause 22. Edited to achieve draft D1. A: Intend to reconcile figure 35.1 with clause 1. Page 3: C: Line 8 - add MII to "GMII maximizes ..." C: Figure 35.2 - Indicate that GTX_CLK is not used below 1000 Mb/s. C: Figure 35.2 - Indicate that TX_CLK is not used at 1000 Mb/s. Page 4: C: Line 44: Strike "The value DATA_COMPLETE ...". This is not in the receive MAC, only in the transmit MAC. Page 7: C: Line 2 etc. - TX_CLK should be GTX_CLK. C: Issue - In GMII mode, should the GTX_CLK duty cycle be 40/60% rather than current 35/65% to rationalize with the PMA service interface? C: Line 24 - Express frequency as 1/8th of data rate rather than 12.5%. C: Can clock slivers be generated by transitions between clocks? Page 10: C: Need to specify that the rising edge is the active edge of the clock. C: Would be better if dotted vertical lines were used to identify each clock. C: Include specific data values rather than "xx" in the figures. Use hex to fit space constraints. Use "xx" for don't care. Page 13: C: Line 7 - "While RX_DV is de-asserted ..." is not correct statement. Need to rework. C: Line 24 - Include RX_ER. C: Are "idle" and "non-idle" defined? A: No, but are used previously in the standard and the use here is consistent in meaning with previous use. Page 14: C: Line 38 - RXD<3:0> should be 7:0. Page 15: C: Why do we have the entry RX_DV = 0, RX_ER = 1, RXD - 00000000 defined as we do? A: This is a 100 Base-T4 legacy. Page 16: C: Add late collisions. C: Figure 35.14 and other Jam issues will be discussed on Tuesday. Page 17: C: Line 6 - Is this frame format correct for the second and consecutive frame of a burst? Page 18: C: Line 7 - Need to limit the shrinkage of preamble. Issue - need to determine the minimum. Page 19: C: Insert a section before management functions to describe extend. A: Will be adding rest of management register set from clause 22. Register addresses currently shown may move. Page 20: A: The 16 bits of the link configuration word may not come from a specific register but may be pulled from various places; for example, fault indication. C: Add a bit to restart auto-negotiation. C: MII should be GMII. Page 21: A: Speed selection needs discussion. Page 22: C: BT should be bT throughout. bT indicates bit-times. C: On link start-up, should the receiver check for 0's in the reserved bits or accept as don't care? Page 24: C: Figure 35-8 - Timing numbers don't belong in a DC specification. C: mA should be uA. C: Need to address clock jitter. Interface with jitter study group. Page 25: C: TBC should be GTX_CLK. C: RBC should be RX_CLK. C: 8B10B should be 8b10b. C: Add signal mapping table GMII <--> PMA service interface. Page 26: C: How is frame burst mode controlled? A: Whatever the MAC chooses to send. Draft D1 - Clause 36 ==================== Rich Taborek presented. Page 1: C: "50 - 2000m" should be "up to 3000m". Page 5: C: Add a description of how to calculate running disparity. A: See fiber channel. C: Need a more clear definition on odd and even. C: Describe reset. C: Describe enable comma detect. Page 6: C: Strike the defined terms signal and sequence ordered set. Adjust the remainder of the clause to not use these terms. C: Line 29 - Difficult to identify undefined ordered sets. C: An alternative specification, which would be easier to implement, would be to default to data codes. C: Allowance for undefined ordered sets is only useful for defining future out-of-band code groups. Repeaters may limit future out-of-band code groups because of idle removal. Use of out-of-band code groups may also be limited if they generate false carrier. A: Allowance for undefined ordered sets leaves an opening for future extensions. This needs more discussion. Page 11: A: Line 34 - K23.7 line may not be correct. A: K23.7, K27.7, K29.7, and K30.7 should not have note 1. C: Should remove unused codes. A: This needs more discussion. Page 12: C: Figure 36-3 - The description could be made more clear if a row is added that defines /C/ as /C1/ followed by /C2/, alternating. Also, add a row that defines /I/ as /I1/ or /I2/ followed by a stream of /I2/. Page 13: A: Line 30 - Note that the running disparity is only the same for a constant configuration word value. C: Line 40 - Strike the term "function" with respect to IDLE. Also w.r.t. Carrier_Extend. Page 14: C: Line 24 - Add a rule for generating T. A: Line 44 - To be updated based on off-line feedback received. Page 15: C: Line 13 - Add description that specific RXD value is associated with Void on GMII. A: Line 15 - Editorial changes are pending which will strike section 36.2.4.12 and merge the relevant information into earlier portions of the clause. C: Line 28 - Define stream. Rationalize with other clauses and previous standards. A: For this clause of this draft, a stream is idle interspersed with packets. C: Based on accepted definitions of packet, there is more than just idle and packets. C: Shouldn't start packet delimiter be start stream delimiter? A: No. One SPD is used for each packet. Page 16: C: Line 7 - TX_CLK should be GTX_CLK. Page 20; C: Line 25 - Could two-bit difference from K28.5 for carrier on be changed to one-bit difference? A: One-bit difference is not accepted as robust enough. A single bit error in IDLE could increment the management counters for collision fragments. C: Note that SPD is very different from IDLE. The choice of 1-bit or 2-bit differences will only affect false carrier generation. A: This affects false collisions. False collisions are very important to repeaters. A repeater would JAM on a false collision. C: Line 36 - Note that both transmit data error propagate and carrier extend error propagate map to VOID. C: Line 39 - What does "*" mean? A: Logical AND. C: Line 19 - Need to add transmit data error propagate as an OR condition to the carrier extend error propagate test. Page 22: C: Line 43 - Should stream decoding be called frame decoding? A: No. This process decodes everything that come in. C: Historically, stream is used for a MAC frame encapsulated by the PCS. This is not the same definition that is currently used in this clause. Page 23: C: Line 33 - Suggest that link monitor enters the link failure state in this event without adding a timer and waiting for a time-out. A: This needs more discussion. Page 25: C: Line 36 - The presence of a SERDES is not clearly indicated by these functional requirements. Page 27: C: Line 7 - Consistent notation should be used when specifying bit-vectors. Sometimes 0:9 is used; sometimes 9:0 is used. C: Table 36-4 - TC should be GTX_CLK. C: Table 36-4 - How did this clause come to specify two receive clocks? A: This table is based on existing parts. A: EN_CDET will be discussed on Tuesday. Page 28: C: The use of RC0 and RC1 is different from the GMII. Detail needs to be added to the description to address this. Page 29: A: Table 36-5 - A presentation is planned for Tuesday to discuss use of these signals. Page 34: C: Table 36-9 - Align with the resolution of byte-time or bit-time. Page 39: C: The scope of this clause is exclusive of the medium. The medium should not be shaded. Also, the scope of this clause is not the entire PHY including PMD. PMD should not be shaded. A: Need to discuss including PMD. Not shading it would conflict with the title of the figure. The purpose of this figure needs to be clarified by the editors. C: Add the MAC control layer. Page 40: C: The comments from page 39 apply here as well. Is this figure redundant? Page 41: C: Where is the mapping from TXD, TX_EN, TX_ER to tx_code_group done? A: In the state diagram. Page 42: C: GTX_CLK direction is reversed. A: Yes. A: Link monitor box includes link synchronization state machine. Page 43: C: Figure 36-9 - An additional, simpler, figure should be added to show the reference points for timing information. C: Figure 36-10 - xxx1111100 is reversed and should be 0011111xx. Page 44: A: Note that VOID is not used in the START_OF_PACKET state. A: Need to add preamble replacement. C: Where is BEGIN defined. A: In state machine conventions. C: There is an issue with the handling of error propagation during the DATA state. C: We don't like the VOID function notation. C: The state machine conventions allow an IF statement to be used in this location. C: VOID is used both as a constant, the code-word, and as a function. This leads to less clarity. C: Is the check for TX_EN and TX_ER redundant in the transition to TRANSMIT_DATA state? C: Should transmitting be set TRUE in END_OF_PACKET_EXT state? C: VOID should not be used in END_OF_PACKET_NOEXT, EPD2, or EPD3 states. A: This needs more discussion. C: The state machine as written ignores the two carrier extension octets potentially sent by the MAC while the PCS is sending EPD. This can shorten packets by two octets. A: This will be corrected. Page 47: C: An issue should be raised as to whether or not the GMII should define a new code point for "in configuration". The 802.3z MAC does not use this but it would be a valuable addition to the standard interface. C: Is RX_ER true and RXD = 0 the best GMII code point to use in the state EARLY_END? Page 48: A: May need to add next page function. C: The correct term for the transition to CARRIER_SENSE_ON should be "transmitting = false AND receiving = false". Page 49: C: It would be more clear if the sync and loss_of_sync diagrams were combined. C: May need to add "AND NOT Invalid" to the transition from Loss_Of_Sync to Loss_Of_Sync. C: May also need to add "AND loss_of_signal". C: A not-equals sign is missing in the comparison of rx_code_group to COMMA. This appeared to affect some print-outs and not others, depending on what platform was used to render the document. C: Should the hold transitions in Acquire_Sync_1 and Acquire_Sync_2 go to Loss_of_Sync instead? C: Should a return be shown from Sync_Acquired? C: Why comma instead of the gigabit Ethernet K28.5? Comma is more general. A: Comma allows existing parts to be compliant. Page 50: C: This is different from fiber channel. A: It was meant to be identical to fiber channel. Differences probably result from transcription errors. Page 51: C: Left side should not include PMA sub-layer. Right side should change from PMD sub-layer to PMA sub-layer. C: The SERDES is shown as the transmitter and receiver. Draft D1- Clause 37 =================== Rich Taborek presented. Page 2: C: Figure 37-1 - The editors will need to determine how best to illustrate the scope of this clause, given that it is not the PCS as currently shown by the figure. Page 3: C: Is priority resolution required? A: Possibly. For example, pause configuration. C: Also when both full and half duplex operation are supported. C: Line 45 - Full duplex should be half duplex in this sentence. Page 4: C: Table 37-1 - What is Link_Configuration_Error? A: Can't bring up the link. For example, priority resolution may indicate no link. C: Note, then, that both sides could independently determine this. It is not necessary to signal it. A: Howard Frazier will be presenting on the topic of remote fault signaling. Page 5: C: How does the next page get transport? A: Work in progress. Draft D1 - Clause 38 ==================== Jonathan Thatcher presented. Page 1: C: Section 38.1.1 should move to clause 1. Also, these acronyms should be shown and unpacked on the first instance of the acronym in the standard. Page 2: C: Line 45 - Should this be signal or loss_of_signal? A: Existing implementations use loss_of_signal. C: 1x9 form factor transceivers uses signal, not loss_of_signal. C: This affects the PCS as well. C: Is 38.2.1.3.1 defining an optical interface or defining a new pin on optical transceiver? A: This doesn't need to be an exposed interface; it doesn't necessarily imply a pin. This section defines a logical interface. C: The loss_of_signal parameter, as defined, seems like a bit error meter. Transceivers can't tell bit errors. Will need to use optical power levels. Page 3: C: Section 38.3.1 needs to specify delay. Delay can affect the bit budget. For example, need to prevent buffered transceivers. Page 4: A: Clarification on 38.3.5. Implementation is optional. If included, the way the implementation performs is not optional. A: Add to 38.4 "... over the lifetime of the product" C: Reference to 37.5.1 is incorrect reference. C: "12 to 300a" should be "2 to 300a". C: "2 to 550b" should be "2 to >550b". Page 5: A: Table 38.2 - Notes will be added to launch power to say "see safety". A: Launch power worst case is actually 840nm not 860nm. A graph will be added to the specification. A: A presentation is scheduled to suggest changes to minimum launch power. Current values were as voted in Vancouver. C: Note that bit rate is the total number of bits transmit to or from. GBd in this table should be baud rate. C: Table 38.3 - Need to specify bit error rate. A: A place will be found in the document to specify the link at 10E-12. C: Vancouver vote may have specified minimum receive power as a different number than the -17 shown. C: Explain footnote a. A: Lots of models have been discussed over the past 6 months. Short wavelength may not achieve 300m on some models due to changing wave shape. It is a work in progress to define the link budget calculation. Page 6: A: Add to 38.5 "... over lifetime of product". C: Is there a reason to specify a maximum distance? A: Not for the PMD. But it is needed for the bit budget. Full-duplex operation is not subject to this maximum, although there may be an effect on link start-up. C: Change "2 to 3k" to "2 to >3000". C: What number should be shown for SMF? Perhaps: 8, 9, 10, or 8 - 10. C: Need to be more clear on what range of distances an implementation must support. A: Need to support 2 - 3000 meters to be compliant but may support much greater range including shorter and/or longer distances. C: Much discussion on minimum maximums and maximum minimums and the need for a better expression of distance range requirements and allowances. C: What to do with jitter? Replace with eye diagram? A: Now is the time to look at the fiber channel jitter work. C: Table 38-5 - Should RIN max be -116, -117, or TBD? Page 7: C: Table 38.6 - Baud rate vs. bit rate discussion erupts again. Add in symbol rate, this time, for spice. C: Where are nominal operating temperatures specified? A: Vendor specifies. C: Where is power measured? A: Open bore and coupled power, both are specified. C: IEC specifies open bore. A: Yes, this standard will look at that and not be redundant. Page 8: A: Modal noise will be divided into SWL and LWL. Page 9: A: May not have a receiver eye diagram, depending on where jitter study group left off. Page 10: C: Line 32 - FDA is not Federal Drug Administration. C: Need to specify the country. C: ISO would strike this U.S. reference. C: Could replace with "also need to meet all local codes". C: There is an example of that in 27.5.2. C: There is an annex for U.S. references. C: Line 44 - Is there a need for other labeling? For example, LWL vs. SWL? Page 11: C: Should dispersion point minimum be 0.093? C: 50u values seem aggressive. 62.5u values seem conservative. Would like to be more aggressive with 62.5u. C: Should this standard be defining cable plant? C: May be best to find an external reference and use it. C: If this is more detailed, may need to clone-and-own. Page 13: A: Will be adding formulas detailing how to do calculations using figure 38-3. Page 15: C: Cable cross-over is not obvious from this illustration. C: Also add text to explain cross-over. Draft D1 - Clause 39 ==================== Jonathan Thatcher presented. Page 1: A: Will be adding a new 39.x on Environmental. See clause 23.9 as an example. C: Line 19 - Reference should be to clause 36 not clause 38. Page 2: C: Figure 39-1 - Remove twist. A: Yes. Some implementations may have it, others may not. C: Change TX to T+, TY to T-, TX to R+, and RY to R-. C: Throughout - Change Imbalance to Differential Skew. Page 3: A: Figure 39-3 - the first 0,9 should be 0,09. A: Bit period will be provided in both UI and %. C: Is this differential amplitude or amplitude only? A: Differential amplitude. The specification intends to consistently use differential peak-to-peak amplitude in milli-volts. Page 4: A: Table 39-2 - Data rate is not required and will be removed. C: bit vs. Baud vs. symbol some more. C: Should copy tolerance specification to transmitter. C: Should note that tolerance specified is frequency tolerance. A: Figure 39-4 - This figure is not the same as voted in Vancouver and requires an official vote to remain as shown. Page 5: C: Clause 27 may be a good model for grounding specification. C: Many separate meetings, apparently on the lack-of-wisdom of grounding both ends of a cable, but no official comments. Page 6: C: Table 39-4 - Need to know the frequencies that the cable needs to be test over. A: Actually, need to know run lengths. Run length is 1 to 5. C: Specify connector vs. specify assembly? A: This is an action item. C: Line 20 - "full duplex links" can be confused with full/half duplex mode of operation for the network. Strike "full" and use "duplex links". C: Line 33 - Add a note that IBM type 1 STP may not meet the link segment characteristics due to total skew. C: Indicate that when compensation networks are embedded in the cable, cables cannot be concatenated. Page 7: C: How are cable characteristics measured? A: Need to find out which external documents to reference. C: Table 39-5 - What does an entry of "---------" indicate? A: Read these entries as don't care. Certain environments may dictate specific values. A: The information needs to be organized such that it specifies a qualified assembly. Additional information may need to be specified. Existing information, such as loss data, may need to be translated so that it can be applied to an assembly. Page 8: A: Note that connector issues are scheduled to be addressed in the March meeting. In the March meeting, the current connector may be replaced. C: Strain relief should be specified. A: Strain relief is application specific. Draft D1 - Clause 41 ==================== Stephen Haddock presented. Page 1: C: Figure 41-1 - Show MAC CTRL layer. Page 4: C: Line 45 - Is the current specification for preamble regeneration sufficient? Should the specification be changed to require a repeater to output a full 64 bits of preamble? A: No, 64 bits is not required, but there is room for discussion on what should be specified. Page 9: A: "BT" is byte time in this version of this clause. Page 11: C: Should the repeater specification be changed so that a repeater uses CRS instead of RX_DV? A: That depends on the solution accepted for preamble regeneration. A repeater may want to look at CRS to protect against cases where the SPD was lost. Otherwise, a lot of data could go by undetected by the repeater. C: What to look at COLL signal because RX_DV, RX_ER may be delayed too long. C: The 100 Mb/s repeater specification has an exit from the JAM state to the repeat state. Omitting this, as currently shown here, will add 1/2 of a slot-time delay to the port that was transmitting. C: The current exit condition from IDLE to JAM is also true for normal interframe gap. This transition requires more qualification. C: Why does a carrier extend error cause a transition from REPEAT to JAM? A: This derives from a coding difference in 8b10b. As compared to previous repeater specifications, this clause has combined the data handler into the core. C: Why is collision generated back to the source port? A: The source port needs to know. C: I meant - Why is error propagation is sent to the source port on a collision? A: Sending error propagation to the source port avoids potential problems when a collision occurs in the carrier extension. C: Does a receiver discard the frame based on length or on receiving Void? A: There are two criteria. For a legal collision, discard is based on runts. For a late collision, discard relies on the frame check sequence but the FCS is not forced to be invalid. A potential problem with late collisions between 56 and 64 bytes is that JAM can increase the size of the frame to a legal size. Using the error propagation code word simplifies the repeater state machine because separate error propagation and JAM states are not required. Recall that Void is not an invalid code word. A: Yes, but Void should indicate a bit error. Using Void to signal collisions aliases a normal network condition together with an error condition. A: On late collisions, JAMming with more carrier extension does not corrupt the FCS and the frame will be of legal length. In that case, the receiver would accept the collided frame. Possible other solutions include JAMming with data or exploiting the changes made to the 1000 Mb/s MAC, which interprets data following Extend as an error when the data is not SFD. C: Need to not repeat link configuration. Page 13: C: The transition from COLLISION_COUNT_IDLE to WATCH_FOR_COLLISION used to be CRS only in previous versions of your state machine. A: Carrier is defined to always encompass collision. Thus the previous and current terms are equivalent. C: The WATCH_FOR_COLLISION state is now redundant. A: Yes, this state became redundant due to specifying the repeater at the GMII level. C: Note that there are maintenance changes is progress on existing repeater specifications. Page 14: C: Select a more appropriate name for FCCLimit. Page 15: C: Line 52 - The description of inter-repeater links is not required at 1000 Mb/s as only one repeater is permitted. C: However, the description does apply to a segment between any two boxes. C: It may be best to move this description to the -CX clause. Page 17: C: Line 22 - Labeling for cross-over ports only applies to 1000 Base-T. There are no cross-over ports in 1000 Base-X. C: The sentence is still correct as written. C: Technically yes, but it may cause confusion. Page 18: A: Will split FX into separate items for LX and SX. Draft D1 - Clause 42 ==================== Stephen Haddock presented. Page 1: A: Discussion of what to say about buffered distributor is planned for Tuesday. Page 2: C: Figure 42-2 - Show some 10 Mb/s. Page 3: A: Table 42-1 - the values 125 and 139 are reversed. Page 4: C: Figure 42.3 - Why "w/ GMII"? A: It is not required; however, historically there have been different specifications depending on whether the MII was exposed or not. C: Table 42-2 - The footnote indicates that there is no margin. There is margin for fiber. A: Yes. C: The bit budget for fiber in the DTE-DTE case should allow at least 300m. A: The calculations may have incorrectly included the delay from a repeater. C: How can 1000 Base-T be included in this table? A: The bit budget for 1000 Base-T is already allocated. Thus, it can be included in this table. C: The table is missing 1000 Base-CX. A: There is no requirement to specify the bit budget for 1000 Base-CX because the maximum link is so short, but it will be included in future revisions. Page 5: C: Does 1000 Mb/s need to include a description of model 2 or could a set of elements be specified that could plug into clause 29? A: It is possible to reference clause 29 or to make the required changes in clause 29. This needs more investigation. Page 6: A: Table 42-3 - Need the numbers for 1000 Base-CX. Page 7: C: For model 2, a user needs to know the -CX delays in order to calculate how long the fiber tail from a repeater can be. A: This information is included in Table 42-3. Distribution of minutes ======================= The minutes from Vancouver, 1996 Nov, were distributed. === Tuesday 28 January 1997. Track I System/MAC/PCS/PMA/Repeater 802.3z CSMA/CD Repeater ======================= Stephen Haddock presented. Page 7: C: Should Void be used during JAM? C: This involves all 3 tracks. C: This could be a long discussion. Let's get the presentation out of the way first. Page 10: C: The terms specified for the PREAMBLE to JAM transition will cause a collision on any receive error. A: The solution is to add a specific error propagation state. Transmit data error propagation - ERROR: TX_EN(ALL) = 1, TX_ER(ALL) = 1. C: When in REPEAT and waiting for carrier to go quiet, it was said that the repeater would propagate IDLE. Is this because the repeater is copying code-words from receive to transmit? A: Yes. C: It is possible for CRS to be de-asserted before RX_DV. For example, a particular PHY may be using a deep pipeline. A: CRS from the transmit ports is still being looped back to the repeater core. C: The repeater operation should only rely on CRS from the receive port. It is bad style to rely on loop-back CRS. Notice that this effect will lock-up the JAM state. Should 1000 Mb/s adopt the 100 Mb/s solution which inhibits carrier from the transmit port(s)? A: Would people be more comfortable with a filtered CRS? C: Can't use both a filtered CRS and the GMII interface. A: Yes. The GMII specifies a maximum CRS delay. C: The repeater could be blind to receive CRS on the transmit ports if a filtered CRS is used. A: No. C: Is it possible to get a collision where neither RX_DV nor RX_ER is asserted? A: No. C: It could theoretically happen. For example, RX_DV may never come on during a collision. C: Is a transition required from IDLE to JAM in the event of multiple carriers? A: Adding that transition would add some robustness. As it currently specified, that transition is made indirectly via PREAMBLE. Note that in the state machine notation, states are timeless. C: When is a start delimiter sent by the PCS? A: The PCS sends a SPD only on rising edge of TX_EN. C: Should a state be added for the condition when there is only one transmitter left on after a collision? A: It was realized at the end of 100 Mb/s that the 1 port left state was redundant with the REPEAT state. A: The repeater will switch to use a filtered CRS. C: Will filtered CRS be accomplished using a timer or using a variable? A: There has not yet been a decision on how best to produce a filtered CRS. C: How can a conditioned CRS be produced for the transmit ports? A: The GMII specifies a 2 clock delay, maximum. There are two possible solutions: send 2 extra characters or send 2 extra idles. The PCS uses these two characters to insert the EPD. C: Would it turn on in the one you are receiving only? A: Only if the IPG shrinks to 2 octets. Just looking at CRS would not work in a multiple repeater topology; however, 802.3z does not include a multiple repeater topology in its objectives. C: A 2 octet drop-out could be generated by errors. A: In any legal condition, this would not be a problem but it could happen. C: If RX_DV is not asserted, won’t RX_ER be asserted? A: It is possible to have preamble without a valid SFD. Thus, RX_DV may never assert. The preamble state accommodates this. Clause 30 Management Additions for 1000 Mb/s ============================================ Howard Frazier presented. Page 5: C: Are you suggesting that gigabit support and update both formats. A: I am suggesting that gigabit does not bother with GDMO and jettison GDMO for gigabit and for legacy. C: How is a buffered distributor manageable without a MAC? A: A managed buffered distributor could have 1 MAC per box to send and receive. Page 6: C: The buffered distributor entity relationship diagram has a lot in common with the one for a bridge. C: What is BufferedDistributorPort for? A: This becomes more obvious when you see the list of attributes. C: For the buffered distributor, this serves the function usually provided by the MAC entity. C: Why is BufferedDistributorPort below the MACControlEntity? A: This is the same relationship as between MACControlEntity and MAC. This relationship is needed so that it can block data during pause. C: Why is ResourceTypeID shown twice? C: This may only be needed if it is an exposed interface. A: Yes. Page 7: C: What is different from the repeater MIB? A: Some repeater object classes were not relevant. I also thought that it would be confusing to have a buffered distributor's object classes begin with "repeater". C: Does TotalIsolatedPorts refer to auto isolation? A: It is possible that a buffered distributor may have auto isolation. For example, it may have something similar to jabber isolation. C: When would a buffered distributor isolate a port? A: I don't know. This entry might be deleted. C: There is an administrative ability to enable and disable ports in a box. C: Previously, there was a decision to not include attributes that could be derived from other attributes. A: Yes. I agree with that policy and TotalIsoltatedPorts appears to go against that policy. Page 8: C: Where is Group? A: It didn't change, so it is not in the presentation. Page 9: C: Should SymbolErrorDuringPacket be SymbolErrorDuringCarrier? A: I didn't intend to change this object class. I will check into it. C: It is possible to reduce counters by moving OctetsXmittedOK and OctetsRecvdOK up to the box level. C: Do we have enough understanding of what is in a buffered distributor to perform this exercise? A: We will have that discussion later. Page 10: C: Where is the MAC address for a managed buffered distributor? A: The address would be at the box level, not 1 address per port. Page 11: C: You include a number of counters in the basic package. In prior standards, the basic package never included an obligation to run in real time - that is, to keep up with traffic. A: Yes, I was aware of that but I don't agree with that choice. Gigabit Management Approach =========================== Paul Woodruff presented. Page 2: A: IETF still has not signed off on 100 Mb/s management. Page 3: A: Value of GDMO is its formal syntax for entity relationships. It is also used to determine, for example, how big to build counters. Gigabit cannot assume 32-bit counters; some counters may need to be 64 bits. Page 4: A: The extended timeline for MIB through IETF refers to standard protocol implementations. Page 5: C: This approach has another con: 802.3z could do one in an IEEE arc, then IETF could define a different one. A: I agree. After his presentation was over, Paul asked for a show of hands for volunteers willing to take part in this activity. 9 people indicated that they were willing. C: How a person votes on this may depend on which approach is selected. Howie: The editors assumed that we would do management as we have always done and work with IETF as always. My opinion is that other conversions belong in 802.3, not 802.3z. Pat: Many people such as myself will still need to go to IETF. If the work were no longer consolidated in IETF, we would then have to go to both. Pat, Paul: The structure does not hold back IETF. Delays are usually due to shortfalls in people to do the work. To Spec Or Not To Spec Buffered ... Repeater / Distributor / Switch ... or Whatever ============================================================ Moshe De-Leon presented. Page 5: C: Would buffered distributors force 802.3x to make flow control mandatory? A: Historically, flow control is optional. Flow control is mandatory for operation of a buffered distributor unless it has an infinite buffer. Page 7: In place of slides 7, 8, and 9, Moshe drew two, four-port boxes on a fresh foil. He spoke to this diagram illustrating: - many issues that he believes remain to be resolved in how a buffered distributor operates - that a useful buffered distributor may have more capabilities, including half-duplex ports and/or dedicated up-links, than the current description indicates, and - that inter-operability problems can arise when using buffered distributors. The points are largely covered by his slides. A: Two buffered distributors interconnected on a link with symmetric flow control will reach deadlock when each has a frame to send to the other. C: An unmanaged buffered distributor needs a MAC address to put in flow control frames that it originates. C: Is it correct to characterize buffered distributors as no- frills switch? A: Yes. C: No. It is a new entity. The chair cut off discussion. To spec or not to spec, II ========================== Howard Frazier presented. Page 3: C: Could you be specific about what option 2 would include in order to provide guidance on the use of asymmetric flow control? A: Maybe restrict asymmetric flow control to buffered distributors. Alternatively, just show how one device would use it. C: We don't specify how to use symmetric flow control. Our specifications are traditionally tight. Why water down this specification with some treatment of asymmetric flow control? Page 4: C: Option 2 lists as a minus "Not much hope for inter- operable management, consistent topologies". Do we have this today? A: We strive for it, there is value to it, and without a MIB spec we don't get it. C: Can't be partly inter-operable. Can't have inter- operability without PICs. A: For example, option 3 may not need to specify maximum forward delay. C: Yes, it would need to specify that. C: I think that option 3 is worse for users than option 1. Option 3 promises that the standard will deliver but it doesn't. Option 1 leaves it to the vendors. C: Clarify the difference between options 3 and 4. Option 3 requires "shall" statements. Won't this creep to become option 4? A: Showing two options may be splitting hairs. While both options allow some behaviors to be fully specified and inter- operable, option 3 allows non-critical areas, such as arbitration, to not be specified. C: Where would option 3 draw the line? A: We would decide in this session. Then, if a new inter- operability problem was found, it would be addressed. C: Flow control is difficult even for groups that focus on it. 802.3 moves in small steps. The buffered distributor is biting off a big chunk - there are a whole lot of issues. Specifying the buffered distributor may be more difficult than the jump to 1000 Mb/s if we do a decent job of it. C: I see that we either don't do it, take a schedule hit, or do a crappy job. C: I don't want us to do a crappy job. Moshe's excellent questions =========================== Howie Johnson presented. This was not a scheduled presentation. Howie offered this presentation, based on an e-mail message that he sent to the 802.3z reflector, to help the group address questions raised in Moshe's presentation. Page 1: C: How is a buffered distributor not a strict subset of a switch? A: A buffered distributor does not make routing (sic) decisions, so it doesn't participate in spanning tree. C: Why can there be only one buffered distributor in a row? A: Many issues arise if there are more than one. A user could cascade buffered distributors with a bridge. C: Is one the best answer? C: Can we know that we are offering a quality standard if we don't first try to offer more than one? C: We need to be clear so that vendors are consistent and users understand. A: I recommend specifying the topology rules to prevent loops, in order not to involve spanning tree. A: On the 10 km length - I suggest that implementations need to provide 2 km and may provide up to 10 km. C: What sets this limit? A: A new kind of bit budget: buffer depth versus transmit- off delay. C: 802.3x introduced a management parameter that covers buffer allowance for link delay. Currently, 802.3x does not put a floor on this parameter. Page 2: C: Wouldn't the capability to support symmetric flow control on each port, as you suggest, obligate every port to parse received frames? A: Yes, but I don't believe that this would have a big impact on buffered distributors. C: Wouldn't a buffered distributor need a MAC address for pause? C: Receivers ignore the source MAC address in pause frames. C: For good reasons, 802.3x requires the source address of MAC control frames to be the address of the originating device. C: If an implementation supported VLANs, would that support prevent it from being an 802.3z-compliant buffered distributor? A: Yes. C: If it could be defined as a hybrid device, it could be standards compliant. C: The e-mail suggests adding a requirement to have outgoing frames appear in the same order on every port. If this requirement was adopted, would outgoing frames need to be appear simultaneously on every port? A: No, just in the same order. Page 3: C: If the propagation delays were set at the same limit as 802.1d-compliant bridges, this would affect the maximum bridge delay and would impact the 802.1 configuration rules. C: You suggest providing enough buffers in each port to manage flow control on a 2 km link. An alternative is to provide enough buffers in a port to support the maximum link of the port’s specific media. For 1000 Base-CX, for example, this alternate value may be much smaller. C: This presentation specifies a product. There is and will be debate on every one of these answers. C: Would a buffered distributor need to support packet burst? A: No. Packet burst only applies to half-duplex operation. C: Does symmetric flow control imply that a buffered distributor could be paused? A: I believe that users should have this choice. C: Does the existence of buffered distributors mandate the capability for full duplex operation and flow control in every 802.3z-compliant device? A: No, this can be left to link configuration. Page 4: C: How many MACs are in a buffered distributor? A: There is only a requirement for 1 MAC. A buffered distributor port could be defined to be a subset of a MAC. C: Pausing a buffered distributor could add delay. This leads to a requirement for a buffered distributor to time- stamp received frames and to check the time-stamp before transmission. C: The buffered distributor was originally positioned to replace the repeater. Now that 802.3z has a CSMA/CD repeater, why proceed with a buffered distributor? A: A buffered distributor provides a significant performance increase relative to CSMA/CD, making it a useful device. It is also good to introduce a new device now, before it is needed at higher speeds. C: How many MACs would a buffered distributor need for flow control? A: 802.3x does not mandate a MAC to send and receive MAC control frames. C: The 802.3x service interface is defined only to the MAC. A: An implementation could be built without the MAC and not be different externally. C: A buffered distributor would have a logical MAC per port from a standards perspective. A vendor could shared hardware is desired. C: A full duplex MAC is fairly simple. It is not clear how a buffered distributor port could be less. C: I would like asymmetric flow control for buffered distributors only. I believe that is how to interpret the motion passed in Vancouver. C: I did the work for my presentation to allow switch to end-station connections to use asymmetric flow control. I believe that the switch to end-station requirement is independent of speed. That is why my Asym_Dir solution is backwards compatible. I did not interpret the motion in Vancouver to justify including a description of buffered distributors in the standard. C: Switch backplane bandwidth is an implementation issue and is not standardized. 802.3x today allows switch vendors to hit the buffered distributor price point if desired. C: The buffered distributor drops spanning tree and other capabilities. C: Any managed device will include a micro-processor. The spanning tree algorithm uses very little real-time. So the only significant difference is the lack of address tables. -- Lunch -- GMII Issues =========== Presented by Bob Grow. There were no handouts. Bob presented: Use of the basic register set: - speed selection (currently requires 10 or 100) - isolate - auto-negotiation management - PHY capabilities - fault reporting - is there a configuration register or are the bits pulled from different places? Collisions and Jam: - late collision extend - late collision burst Discontinuities: - signaling errors in IDLE - link configuration - electrical interface - preamble shrinkage There was no discussion. GMII Timing Update ================== Asif Iqbal presented. Also by: David Fifield, Jayant Kadambi Page 2: C: Change "Long Haul Copper PHY Interface" to "GMII Interface" C: Where is the timing information? A: The timing is unchanged from my presentation in Vancouver. Page 3: A: The MAC to SERDES interface uses: 8ns cycle, 125Mhz, and global synchronization without a PLL in the MAC. (Secretary's note: There is no MAC to SERDES interface in 802.3z. Most likely, this is intended to be the PCS to PMA interface.) C: Define what is meant by clock insertion delay in MAC? A: Consider a path where the clock is brought to the MAC input pin, then a clock buffer drives the clock tree. The clock insertion delay is the clock buffer delay and the RC delay to the flip-flops. C: Where did you get the value for the clock insertion delay parameter? A: I based it on available technology. C: Why can't a source synchronous solution be used? A: Existing parts do not operate that way. Also, the MAC would have difficulty meeting the clock jitter specifications. C: Where did you get the number for clock to data valid at SERDES? A: It is based on typical PCB track lengths from the MAC to the SERDES. The 10-bit interface uses a 10pf lumped load. C: In the 10-bit meeting this morning, it was tentatively agreed to change the hold time to 1.0ns and the set-up time to 2.0ns. A: These numbers do tend to change. What is important is the total window. How the window is shifted towards set-up time or hold time does not matter to this timing budget. Shifts in the window are accommodated by adding or removing clock delays. A: The MII specifies a 4mA buffer at TTL levels. I believe that this timing can also be supported using MII buffers. GMII Electrical Specification ============================= David Fifield presented. Page 9: C: The note on MII mode would be better placed in the GMII clause than in the System Considerations clause. Page 10: C: The illustration is missing an inductance, which would be approximately 10nH. A: The inductance was considered in the models. Inductance is not normally required for datasheets. C: The delay from 3 inches of PCB trace is getting to be on the same order as the edge rate. Thus, a lumped model will not be accurate. C: A 3 inch limit for the PCB trace may not be sufficient for devices, like repeaters, where multiple SERDES are used. A: These impacts were not considered in 100 Mb/s. In this case, we may also not want to get into this as a specification. In an implementation, a vendor may achieve a longer track. Products would be limited by the feasibility of drivers, unless they go to an integrated solution. An integrated solution would be better. C: SERDES vendors prefer not to specify the output driver strength, just the timing. Page 11: A: How does station management detect PMD type? C: This is a slippery slope. PMD vendors may not want to add this. The chair halted discussion on this topic. Page 12: C: The MAC and MAC CTRL layers are shown in the wrong order in the NIC. These layers could be left out of the figure. Collision and Jam ================= Stephen Haddock presented. There were no handouts for this presentation. Steve drew: |<--- 512 byte collision window --->| | Preamble | Data | Extension | Jam | |<--- minimum extended packet 512 bytes | A: A late collision relies of the frame check sequence for discard. With carrier extension, the FCS is valid and thus the late collision fragment appears valid. The frame becomes duplicated if it is re-transmit by the originator. A: Possible Jam patterns are: 1. EXTEND: This doesn't work. 2. Go back to DATA: This works but is ugly. The MAC must switch to data and the PCS will send a new SPD. Thus, the stream looks like 2 packets, not Jam for the first one. 3. VOID: This also works. C: In option 2, what is the mechanism to send VOID. Only the MAC knows and the interface does not currently tell the Reconciliation Sub-layer. A: Yes, the current MAC does not signal error. C: The MAC as written goes back to sending data bits for JAM size. The data bits are derived from the start of the frame. C: How does the PCS distinguish between Jam data and a new frame? A: It doesn't and it doesn't need to. To do so would require the MAC PASCAL to increase the physicalBit enumerated set to 0, 1, EXTEND, JAM. C: The PCS could tell by detecting the EXTEND to DATA transition, where the data was not preamble, together with COLL. C: Option 3 obviously works. A: Once past 512 bytes, both the transmit and receive MACs consider a frame done even if EXTEND order-sets are still going out. Thus, after 512 bytes the transmit MAC cannot re- transmit and the receive MAC can and must forward the frame. C: A late collision after the 512th byte looks like a collision on the 2nd frame of a burst. C: What about collisions on the last byte, byte 511, of the carrier extension? A: Such a collision is not a legal collision. The collision window ends 8 bytes before that. That would be a late collision. C: Option 1 will work if the originating MAC doesn't re- transmit. A: Yes. The transmit MAC cannot tell if the transmission was successful and would be O.K. if it never re-transmitted. C: I suggest that late collisions be specified as normal transmissions with success and be done with it. C: That would produce a weird behavior. Legal collisions would be handled normally. Slightly late collisions would be ignored. Later collisions would be handled as late collisions. C: We could specify that the originator never re-transmits on late collisions. A: Yes. This lets us ignore if a third party could have received the frame. C: It would be different from 10/100. C: It would make the MAC definition dependent on speed. C: The 32-bit JAM was never needed if 96 bits have already been transmitted. A: Yes. An easier and better change might be to not Jam if beyond 96 bits. C: How about: Don't JAM if you are in extension. Extension code is already new code in the MAC PASCAL. C: Why do we want to mark it as a bad packet. A: Someone else may have detected the collision earlier and/or received invalid data. C: Re-transmission on late collisions is of marginal value. C: What about a 1500 byte frame? A: As before, collision detection for long frames depends on an FCS error. A: Now we need to work on the bursting case. Register Set ============ Bob Grow presented. There was no handout for this presentation. A: Speed. Speed is signaled by bit 13. It is 10 or 100 Mb/s. I suggest that 1000 Mb/s defines a new bit to over-ride bit 13. A: Isolation. Do we need to isolate a 1000 Mb/s PHY? C: This is needed if it is a 1000/100 PHY. C: This was used in the past for live insertion. It was also used in the past to support multiple PHYs on the same MII. Multiplexing and de-multiplexing was accomplished by isolating the PHY(s) that were not in use. I don't see a need for either of these at 1000 Mb/s. A: Auto-negotiation. With this in the base register set, how should GE deal with link configuration? C: This is a clause 36 issue. The GMII interface needs to provide access to the auto-negotiation register set. A: Status. How to define PHY capabilities? C: Bits 10 - 7 in the base register were available. T2 used 1 or 2 bits. C: GE should use one bit and use that bit to add a register. A: The current configuration register shares bits with other registers. I prefer that the bits in the configuration register not be redundant. Instead, I suggest that the configuration bits are drawn from the current and new register set. What do we want to duplicate and what not? This is the difference between a real register and a "configuration word". C: Draft D1, register 1 - where does it go to? A: I recommend to dissolve it and draw from whatever register positions. C: The clause 22 registers? A: We need to look at all of the registers and see how many fit with GE. C: For 1000 Mb/s operation, I recommend that we should add to the register set, not change it. A: We need to work in the base register so that it is possible to tell what to look for in the new registers. C: Yes, but don't delete bits in existing registers. Just say that these bits have no meaning at 1000 Mb/s operation. This method has been used previously. Errors in IDLE ============== Bob Grow presented. There were no handouts for this presentation. A: I suggest that we signal false carrier for errors in IDLE. C: The PCS only signals false carrier on a 2-bit difference (from K28.5). Otherwise, it just stays in IDLE. I think that this is not an issue. Link Monitor in 802.3z/D1 ========================= Wen-Tsung Tang presented. Also by: Stephen Haddock Page 3: C: Is this timer needed? Would it be better to detect the change in configuration word value? A: The link monitor cannot always detect the change. C: At least the ACK will go away. The chair halted discussion on this topic. Page 4: C: Where is configuration mis-match set? A: Configuration error is not included. It comes later. It has been defined on the reflector after this work. Page 7: A: Top right "C" should be "CAck". Page 8: A: Top diagram, right station, should show the Link_Not_Avail state between the Tx_Ack and the Link_Config states. Page 9: C: If the timer was used only after sending Cnew, the protocol may still operate correctly. A: Yes, that is probably true. Page 10: C: Does the configuration word sent with CAck need to match the configuration word captured from C? A: Yes. C: If it becomes corrupted such that it is not even a valid C, what is the behavior? A: These are dropped. C: You suggest MAC control frames instead of next page. What non-essentials might go in MAC control frames? A: Anything after speed and other base functions that might be required to get the link up. C: How would this solution accommodate repeaters? Repeaters are missing the upper layers to send and process MAC control frames. C: I prefer to have the next page function. Note that it is optional and so a vendor doesn’t have to implement it. A: The process is mandatory. C: In auto-negotiation, the process is mandatory but next page is optional. The chair halted discussion on this topic. C: What does the probability of reconfiguration table illustrate? A: It shows that link configuration does not guarantee link quality. C: A station could potentially wait longer to get a bit error rate. Review of Clause 36 PCS: Link Monitor & Synchronization ======================================================= Devendra Tripathi presented. Page 4: C: Loss_of_Sync is the same name from the bit synchronization state machine. This not the best or most accurate description of this state. A: Yes, may call this state Idle or Wait_For_Sync. C: What is the purpose of this presentation? Is it to try to re-acquire sync during IDLE or packet transmission? I suggest only trying to acquire synchronization during configuration. This is identified as an issue. Why is your presentation discussing how to when we don't know if we want to? A: My purpose is to make the Link Monitor simpler and to correct bugs that I identified. Page 5: A: Add "* enable_config * not off-line" to the transition from LINK_NOT_AVAILABLE to LINK_CONFIG. A: Change receive_idle to idle_match for the transition from TX_IDLE to LINK_OK. A: Add "+ not signal_status" to the transition from LINK_OK to LINK_NOT_AVAILABLE. C: How does this relate to the previous presentation? It seems that two states have been deleted. C: Latching of receive acknowledge is implicit in state TX_ACK of this state machine. In our previous presentation, we changed the state machine to make this latching explicit. C: What does the notation "(=C1)" mean? A: This notation matches the timer load with the timer check. C: This is not a standard notation for this group. A: My presentation is not proposing a format, just a behavior. Clause 28 Auto-Negotiation and 1000 Mb/s Link Configuration are Different =========================================================== Howard Johnson presented. Page 7: C: Are the 100-T2 bits correct? A: I believe this is the most recent. C: I don't think these are claimed by T2. 802.3z could use these two bits as two bits of remote fault information and still have the same format as auto-negotiation. A: I prefer not to get involved in the tangle of negotiation for precious bits. C: I agree. It seems best for link configuration to use a compact base page and avoid the complexity of next page today. C: Do we need a resolution table? A: Yes. I believe that the resolution table promotes inter- operability. C: I don't care what the format of the configuration word is, but it is important to maintain the register set. I also suggest that link configuration use the clause 28 state machines. C: Why is it a feature to have two different base pages? A: Having a unique base page for link configuration makes it simpler and allows new capabilities to be communicated earlier in configuration. For example, two remote fault bits can indicate why a link is down. C: With auto-negotiation, an infinite number of bits can be read. It is misleading to indicate that this function depends on the whether the bits are in the base page or a next page. A: If the link is broken one way, only the base page gets across. For this reason, more fault bits in the base page are better. Link Configuration Issues/Solution ================================== Bill Bunch presented. This presentation was added to the agenda. Page 9 (numbered 235 in the presentation): C: How does a station re-negotiate? A: Restart of auto-negotiation is accommodated using the global entry into state AUTO-NEGOTIATION ENABLE. This is consistent with the state machine conventions. C: How is transmit disable accomplished in 1000 Base-X and 1000 Base-T? A: I haven't considered this yet. C: A new ordered-set could be defined and used, the VOID ordered-set could be used, or a new control bit in the base page could be defined and used. C: In auto-negotiation, there are state machines for transmit and receive that are not shown here. A: Yes. This is where the misconception arises that auto- negotiation requires fast link pulses. Auto-negotiation could be mapped to new transmit and receive state machines that use other mechanisms in place of fast link pulses. C: An advantage of the approach proposed here is that it comes with fundamental management capabilities. The current link start-up state machines do not include these. A: Yes. This approach reduces the burden of new development for gigabit. --- Wednesday 29 January 1997 A Pause Link Configuration ========================== Ariel Hendel (hendel@eng.sun.com) presented. Page 8: C: Is it true that pause is mandatory for GE? A: Yes. C: No. A: Well then, I propose that it should be. Page 9: C: Who are the senders who must comply with PAUSE regardless of their DP value? C: It reads as the senders of PAUSE. A: It is meant to be the senders of DP. Page 10: C: This appears to be completely compatible with 802.3x by preserving the meaning of the existing flow control bit as is. Link Configuration of Pause Function ==================================== Howard Frazier presented. Page 15: C: If gigabit changes 802.3x, what is the impact? A: We could put in a recirculation ballot comment. C: 802.3x has closed their second recirculation ballot, successfully, 17 January. C: Wait ... I have an outstanding comment exactly on this issue. C: That comment was never received. A: Where there is a will there is a way but changing 802.3x now could break existing implementations. C: Suppose gigabit wants to introduce asymmetric flow control into auto-negotiation. A: I assume that GE would go back and introduce Asym_Dir into the 802.3x annex. C: Flow control negotiation doesn't seem to have anything to do with link configuration. Could we use MAC Control frames to negotiate flow control? A: Using MAC Control frames was considered by 802.3x but there are always reasons to reject it as the best solution. C: I don't propose to replace auto-negotiation with MAC Control frames. However, it seems a good fit for 802.3x. C: MAC Control frames were tried in 802.3x by redefining the bit to mean "understand MAC Control frames". The attempt turned into an unproductive rat hole. C: I think that the Pause(r) bit of this presentation maps closely to the existing Pause bit. Mapping the Pause(r) bit to the existing Pause bit seems to be as compatible with the existing bit as Bill Bunch's Asym_Dir solution. C: The example on page 11 seems to indicate that a buffered distributor can’t negotiate symmetric flow control with a switch. C: A buffered distributor could advertise both Pause(r) and Pause(t) to do this. C: It would be better if a buffered distributor did not need to know who its link partner was before it decided what flow control capabilities to advertise. A: I suggest that GE puts configuration of flow control in the hands of the network administrator. I agree that GE does not want the network administrator to have to go out and configure every port but GE should allow the capability. C: It is possible for a buffered distributor to drop the link, change the flow control capabilities that it advertises, and re-negotiate the link. However, I do not like this solution. It is not clear that this method would always converge. A: There are cases where the link does not come up because the capabilities do not match. C: Re-negotiation is not a good choice. The best solution would be to bring the link up and then negotiate other features, such as flow control. C: I don't believe that the Asym_Dir solution has as much capability as the Pause(r) and Pause(t) solution. There is a need to signal "I am a legacy device". The best solution would be to add two bits and new devices can use these. C: The base page is the place to advertise speed independent functions. Flow control should be in the base page and should use the minimum number of bits. Asym_Dir meets this criteria. A: Clause 28, Annex B, is the correct place to modify the standard. C: It appears that there are three potential solutions that use the minimum number of bits: Asym_dir with the existing pause bit; Ariel's proposal; and going back and changing 802.3x. C: Pause(r) and Pause(t) could be used in Link Configuration. They could also be used in 1000 Base-T by including these bits in a next page. A: And there are other alternatives: take new bit(s) in the base page or change the standard for 802.3x. C: Existing implementations have already committed to the base page. C: I think this proposal provides the same capabilities as the Asym_dir solution. Unlike the Asym_dir solution, neither of these bits seems to map to the existing pause bit. MAC and SERDES Timing Budget ============================ Haluk Aytac (haluk_aytac@hp.com) presented. No comments were made. PMA Issues ========== This planned presentation by Michael Yam was removed from the agenda. 1000 Base-X Signals =================== Rich Taborek presented. This presentation was added to the agenda. Rich presented an updated section 3.2.5, Control effect on PHY, from clause 35. This presentation covered GMII control signals, PCS signals, PMA signals, and PMD signals. POWER_DOWN: C: Why has the control register bit to restart auto- negotiation been omitted? A: This may have been an editorial error. I used the table (table 35-6) from clause 35. I didn't know that this bit was missing from the clause 35 table. This bit should be added. C: Speed selection is also missing. A: Speed selection is not a control bit. It is more of an indication. C: Think of these signals as what needs to be added to the base register set for GE. When reviewing these signals, do not worry about what is or is not included from the base register set. RESET: C: What is the impact if SIGNAL_DETECT is not implemented? A: The logic would simply continue with the reset of the reset conditions. C: Would the wait for 2500 bit times still apply? A: The wait is used to support LCK_REF. SYNC_ACQUIRED: C: I don't think that this applies to 1000 Base-T. A: Agreed. It applies to all 1000 Base-X, where synchronization is required at the receiver to the clock and to code-word boundaries. C: The code seems to use SYNC_ACQUIRED but never sets it. A: SYNC_ACQUIRED is generated by the link monitor. C: Why is this code included here? A: The code shows how these signals could interact. C: Is this code proposed as a replacement for the current state machine? A: If GE decides to use these signals, then this logic would need to be added to the synchronization state machine. Also, the track III (1000 Base-X PMD) group is looking for guidance on which of these signals GE would need to support. FAULT: C: What is this signal? A: The transmit laser would assert this signal when it has detected a fault. Typically, the laser would also turn itself off in the event it detects a fault. A reset operation would turn the transmit laser back on. TX_DISABLE ensures that reset doesn't turn the transmit laser on when a previous fault has occurred. PCS Issues ========== Presented by Rich Taborek. This presentation was added to the agenda. Rich presented his current PCS issues list. Rich had not prepared hand-outs but there was a lot of material - too much to include in these minutes. Page 1: C: Are you looking for a straw poll on these issues? A: Yes. I would like to complete the list, hold some discussion on each issue, then take a straw poll on each. Issue (d): Issue (d) dealt with the signaling methods used to transport link configuration information. Currently, auto-negotiation uses fast link pulses and link configuration uses C ordered- sets. A: I recommend staying with C ordered-sets for link configuration. I am not aware of any other solutions. Straw poll: 22 in favor of C ordered-sets, 0 in favor of other signaling methods. Issue (i): Issue (i) dealt with the format used to present the configuration data in the management register set. C: Pulling bits from several registers enables the C ordered- set to use bits in the base page that would otherwise be wasted. C: GE agrees that it wants compatible management registers. C: Contrast issue (c) and issue (i). A: Issue (c) specifies the format of the bits of the configuration word on the wire between stations. Issue (i) specifies the format of the configuration word in the management registers. C: GE uses configuration register incorrectly in a historical perspective. The historically correct name is "advertised register". Straw poll: The straw poll was interrupted by the chair. C: Howard suggested that the group should use a motion to resolve each of these issues. He informed the group that a sub-task force can have motions for issues within its scope. Rich agrees to allow motions to interrupt his presentation Motion I.1: =========== Set the (1000 Base-X) base page equal to the clause 37 defined base page. Moved: DeLeon, Seconded: Thaler. C: Will a yes vote mean that the link configuration base page is different from the auto-negotiation base page? A: Yes. The motion is to accept the current specification given in clause 37. C: Will GE still be able to modify the link configuration base page to accommodate other requirements? A: Yes. The current specification can still be modified to support flow control, etc. C: This motion seems to have no effect. It accepts the status quo. A: The link configuration base page format has surfaced as an issue. C: This group is trying to work through issues that have been raised. Presentations have been made that suggest changes to the link configuration base page format. C: Draft D1 has not been voted in. C: I motion to table this motion. I don't want to go point by point. Motion to table: Yes: 8, No: 19. C: I propose an amendment to change this motion to the NOT version. A: I do not accept that as a friendly amendment. C: If the motion were to written to change the link configuration base page format to the format specified in clause 28, then the motion would accomplish something. A motion in favor of the status quo seems to do nothing. Motion for amendment - Change motion to: Adopt Clause 28 defined base page. Moved: Brier, Seconded: Gritton A: Without this amendment, this group is debating nothing. If the link configuration base page format is to change, a specific target is needed to test against. This amendment does that. C: Can we see the differences in registers? Howie Johnson reviewed slide number 7 from his earlier presentation. Howie deleted the T2 bits, which are apparently in error on his slide. C: The 10-T, 100-TX, and 100-T4 bits would always be zero for GE. C: We are missing the point. The base page is what management sees across the MII. This motion is confusing because it does not clearly say "on the wire". The way the information looks to management is very important. How it looks on the wire is not important. Clause 28 has the advantage of two years of success. Motion for amendment was withdrawn based on the understanding that the original intent of the motion is to define the format on the wire. A: Amend the motion to: Adopt usage of the base page defined in clause 37 for transmission on the medium. A: Agreed. C: It may make sense to first determine how the registers should look on the MII (sic) interface, then to entertain how it should look on the wire. C: The register format could be completely different from what it is on the wire. Vote on the motion: Yes: 28, No: 9, A: 17. Motion passes. Motion I.2: =========== Adopt the auto-negotiation algorithm/architecture as outlined in Bunch Jan '97, Link Configuration Issues/Solution, as the basis for moving forward with clause 37. Moved: Bunch, Seconded: Seifert. A: My comments were made during the presentation. This motion does not conflict with the previous motion because this motion deals with the mechanisms, not what bits are on the wire. C: This motion affects PHYs. We can't make this decision in this group. C: There is nothing wrong with having a position from this group. The larger group could overturn the decision but this group owns this issue for now. C: Does this motion include using next page from the presentation? A: Yes. It also includes using the state diagram. C: The state diagram will be used as a basis. A: Replace the state diagram in clause 37 with the one from the presentation. A: Let's have one logical set of things and not do things anew. C: Speed does affect things. The state diagrams will require modifications. A: I don't believe that the architecture will need to change. GE may need new timer values. C: Next page could just be added to the current state machine in clause 37. A: Yes. This motion does that and also defines how to accomplish it. C: I would prefer to add next page to the existing clause 37 state machine. The existing state machine has been well verified for 8b10b. A: Auto-negotiation has been inspected much more than I have for the existing clause 37 state machine. C: Could this motion affect whether or not auto- negotiation is mandatory at 1000 Mb/s? A: This motion is not intended to affect if auto- negotiation is mandatory. Next page is intended to be mandatory if auto-negotiation is included. C: The state machines seem similar. Does GE want next page? A: Permitting next page to be optional leads to great fights over who gets to be on the base page. GE has no installed base. Don't lock into a mechanism that does not have expansion. C: We don't know what the bits on the next page do, anyway. A: Having the syntax allows GE to add the semantics later. C: Implementations of 100 Base-T that came out pre-standard without auto-negotiation cause many hardships. C: The existing clause 37 state machine could add next page. However, the auto-negotiation state machine has been simulated and built and is known to work well. C: I would like to see a marriage of auto- negotiation with the existing clause 37 link configuration. A: I believe that this motion does that and gives clear direction to the editors. Plus, a mechanism other than auto-negotiation will slow GE down when the standard gets outside of 803.2z. C: The state machines are curiously alike. This motion seems to give the freedom to draw from auto-negotiation. C: I don't read this motion as trying to combine the two solutions. A: "as the basis" gives the flexibility. C: This motion does not suggest the need to be flexible or to draw from what is in Draft D1. C: Call the question. There was no objection. Vote on the motion - Yes: 35, No: 5, Abstain: 18. The motion was classified as technical. Motion passes. ... Back to Taborek's presentation ================================== C: Time management. Rich has time for only one more issue. Motion I.3, technical: ====================== Incorporate MII management register set into the GMII as the basis for adding gigabit specific registers and bits. Moved: Grow, Seconded: DeLeon. (O.K. So we are not back to Rich's presentation) C: Call the question. There was no objection. Vote on the motion - Yes: 65, No: 0, Abstain: 0 Chair Liaison Report ==================== Presented by Howard Frazier. A: Track III decided that SIGNAL_DETECT will be optional and the polarity will not be specified. Track III is undecided on TX_DISABLE - a motion to remove it failed and a motion to make it optional also failed. ************ The following minutes for Track II were provided by Colin Mick (ckm@ix.netcom.com): MINUTES FOR 1000BASE-T SESSIONS January 28-29, 1997 Attendees (1/28/97) PLEASE VERIFY & NOTIFY ME OF ANY MISTAKES ALSO, PLEASE ADVISE ME OF MISSING NAMES (Copper reflector address list has been updated to include new names on the list below.) Mick,Colin,The Mick Group,415-856-3666,ckm@ix.netcom.com Milinarsky,Fanny,Scope Communications,508-393- 1236,fanny@scope.com Agazzi,Oscar,Broadcom Corp,714-450-8700,oea@broadcom.com Hatamian,Mehdi,Broadcom Corp,714-450-8700,mehdi@broadcom.com Campbell,Robert,Lucent Technologies,908-957- 2669,rrcampbell@lucent.com Tran,Hiep,Texas Instruments,972-995-7885,htran@hc.ti.com Wang,Greg,Delta Products,570-668-5163,dcp-greg@deltaca.com Sudjian,Douglas,Microlinear Corp,408-433- 5200,sudjiand@engmail.mlinear.com Debiec,Tom,Berk-Tek,717-354- 6200,tom.debiec@ccm.useable.alcatel.com Ellsworth,Steve,Innet,819-578-8094,innet@adnc.com Hinrichs,Henry,Pulse,619-674-8208,henryhinrichs@pulseeng.com Price,Alistair,Rockwell International,805-373- 4626,ajprice@risc.rockwell.com Gritton,Greg,Adaptec,408-957-2386,gregory@end.adaptec.com Lacerte,Rick,Cabletron Syustems,603-337- 5015,lacerte@ctron.com Jovier,Juan,Level One,908-972-6791,juan@level1.com Rao,Sailesh,Level One,908-972-0707,sailesh@level1.com Parker,Jim,Level One,916-855-5000,jparker@level1.com Munson,Carrie,Pulse,619-674-8207,carriemunson@pulseeng.com Murphy,Dennis,Pulse,619-674-8317,denismurphy@pulseeng.com Rizk,Ramez,Nano Pulse,714-529-2600,rrizk@attmail.com Thomson,Douglas,Ohm Technologies,714-752- 1028,dougt@ohmtech.com Essig,Dan,Rockwell,619-535-3615,essig@brooktree.com Miao,Tremont,ADI,617-937-1222,trement.miao@analog.com Froke,Rich,Compaq-NPD,408-232-9121,refroke@networth.com Oleynick,Gary,Berg,619-634-0723,goleynick@aol.com Hayden,Kirk,Level One,916-854-2871,khayden@level1.com Cady,Ed,Berg,503-359-4556,edcady@aol.com Lee,Howard,Bel Fuse,510-227-0102, Hackler,Brian,T & B,901-680-5991,bhackler@thombetts.com Chu,George,3Com,408-764-6031,gchu@nad.3com.com Overs,Pat,3Com,44-1442-438-074,pat_overs@3mail.3com.com Raghavan,Sreen,Comcore,619-535-0074,sreen@comcore.com Salzman,Michael,Madge Networks,408-952- 9814,msalzman@madge.com Lee,Lance,XaQti,408-487-0809,Lance.Lee@xaqti.com Yu,Mark,Lucent,908-949-2185,my@lucent.com Azadet,Kamran,Bell Labs,908-949-7280,ka@bell-labs.com Hochstedler,Charles,Lucent,610-712- 5462,hochstedler@lucent.com DiMinico,Chris,Digital Equipment Co,508-486-6983,chris.diminico@mts.lkg.dec.com Oh,Stephen,National Semincodncutor,408-721- 2326,oh@galaxy.nsc.com Porten,Joshua,National Semiconductor,408-721- 3338,shooey@galaxy.nsc.com Eisler,George,Rockwell International,310-459- 9225,geisler@aol.com Cam,Richard,PMC-Sierra,604-41506022,cam@pmc-sierra.bc.ca Van Goor, David,DuPont,302-999-3278,2052672@mcimail.com Vafiacks,Todd,National Semiconductor,207-775- 8992,todd@thoreau.nsc.com Grivna,Ed,Cypress Semiconductor,612-851-5046,elg@cypress.com Somer,Greg,Cypress Semiconductor,408-943- 2065,gbs@cypress.com Broadhurst,Denzil,GEC Plessey Semi,011-44-161-684-4025,denzil.broadhurst@gpsemi.com Wurster,Stefan,Silicon Dynamics,408-328- 3244,smw@sidynamics.com Kibinec,Jim,AMD,408-749-4949,jim.kubinec@amd.com Bowers,Rich,GEC Plessey Semi,408-461- 6237,rich_bowers@gpsemi.com Guidon,John,Comcore,818-880-5192,john@comcore.com Easton,Doug,Comcore,818-880-5192,doug@comcore.com Perna,Chris,Comcore,818-880-5192, Agenda 1/28/97 Status Report: Colin Mick: 1000BASE-T Status Report TR41.8.1 Liaison Report Chris DiMinico FEXT Data Chris DiMinico: Channel FEXT/ELFEXT FEXT Data Bob Campbell: FEXT Loss Media Models for 4-Pair Category 5 Cable Line Code Proposals: Sailesh Rao: Update on the Enhanced Tx/T2 Proposal for 1000BASE-T Kamran Azadet: Study of possible line codes for 1000BASE- T Mehdi Hatamian: New Results on QAM-Based 1000BASE-T Transceiver Stephen Oh: Implementation Study of Gigabit Copper Ethernet Receivers Sreen Raghavan: Line Coding Proposal for Gigabit Copper PHY Presentations were made as per the agenda above. Rather than attempt to summarize the presentations (and incur the wrath of the presenters) I refer you to hard copies handed out at the session or check the 802.3z FTP site. I have a hard copy of each presentation. Presenters should post a copy of their presentation to the 802.3Z as per attached call from Howard Frazier In view of the complexity issues raised by Stephan Oh's presentation, all proposers were asked to calculate transistor counts and heat dissipation requirements for their proposals and further technical discussion was deferred until the morning of January 29. The group then reviewed the draft 5 criteria document and directed the editor to revise it for consideration the following morning. Call for # of companies who plan to participate in Standards Development--25 Agenda 1/29/97 Additional discussion of technical proposals Develop action plan Complete review of PAR & 5 criteria Each of the proposers provided their estimates on the complexity of their solutions. NOTE: values are comma delimited , complexity data at 3 dB Company, Line use, Transistor count (incl analog), Heat dissipation (Watts), Feature size (microns) Lucent, FD, 1.5M, 5, 0.25 ComCore, DD, 1M, 4, 0.35 Level One, FD, 1M, 4, 0.35 Broadcom, FD, 1.3M, 4.2, 0.35 National, DD, 1M, 4, 0.35 1000Base-T accept no additional line coding schemes after 1/29/97 M: Tran S: Mick Y: 15 No: 20 A: 5 MOTION FAILED Add two additional criteria to the comparison table: estimated gate count and power consumption/launch voltage. M: Gritton S: Froke Y: 39 N: 0 A: 1 MOTION PASSED Motion to establish a schedule for 100BASE-T- March 97 Select Line Code July 97 Draft Proposal November 97 WG ballot March 98 LMSC Ballot July 98 Approval to send to Standards Board Moved: Mick Technical Motion (requires 75 %) Second: Hayden Y: 22 N: 10 A: 2 Motion Failed Motion to establish a schedule for 1000BASE-T July 97 Select Line Code September 97 Draft November 97 Contingent approval for WG ballot March 98 Contingent approval for LMSC ballot July 98 Approval to send to Standards Board Moved: Mick Second: Vafiacks Technical Motion, requires 75% Y-38, N-0, A-1 Motion passed PAR Motion 1/29/97 I move that the group accept the PAR & 5 Criteria as amended and direct the editors to: 1. Forward to 802.3z for review and approval this afternoon. 2. As per the November plan: A) Forward by February 6 to the IEEE Standards Office fir inclusion in the February 7 NESCOM package; B) Forward to the IEEE 802 Executive Committee by February 6 to meet the 30-day review requirement; and C) Present to 802.3 for final review and approval at the March '97 Plenary. Moved: Mick Second: Hochstadler Y-27, N-0, A-0 NOTE: The PAR motion passed in the 802.3z meeting Announcement of 100BASE-T tutorial Monday, March 11 8pm and call for tutorial presentations. (The tutorial was formally advertised in the mailing for the plenary-we're committed! Meeting adjourned Colin K. Mick 2/3/97 **************************************************************************** Minutes from the IEEE 802.3z interim meeting held in San Diego California on 27 - 29 January 1997 Track III - Optical and Short Haul Copper These minutes will include the order of the presentations and the discussion about the presentations but do not include the presentations themselves. All presentation material should be available on the IEEE web page and should have been sent out in text form on the reflector. If you have additional questions about the presentation material please contact the author of the presentations. Where possible I have included the authors name and email address. The track III meeting was opened by Jonathan Thatcher with a call for a recording secretary. John Bowerman of Honeywell was identified. A proposed agenda was presented and Jonathan asked if there was any objection to grouping the Copper presentations and presenting them first. No objections. Jonathan asked if there were any additional presentations that currently were not listed on the agenda. Several additional presentations were identified ( See agenda ) Jonathan asked that presenters highlight areas of contention and material that they wish to use as a basis for motions later in the meeting so that the items can be thought about and discussed prior to a call for motions. **************************************************************************** Presentation 1 PMA Issues - Mike Yam - Vitesse Presentation was to point out three mistakes in the 1st draft and to propose changes to them. Discussion: Shelto Van Dorn: Are these changes mandatory? - No Paul Kolesar: This implies that in copper there is no intelligence, Is that your intention here? - Yes Mark Sankey: I would like to see the jitter of the clock included unlike current chip specifications. Jonathan: Was planning on addressing that during the 8b10B and Jitter discussions. Changes will be included in the joint presentation by Jonathan Thatcher and Rich Taborek ?: If comma_detect is disabled does alignment occur? Jonathan: No **************************************************************************** Presentation 2 Gigabit Ethernet Equalized Cable Loss Characterization - Ed Grivna - Cypress Semiconductor Presentation described the calculations for determining if a 1000Base-Cx link can support 25m link operation while meeting its link loss budget. Conclusion presented was that it could justify 25m copper links. Discussion: Del Hanson: Have you compared this model to real world measurements? Ed: No but I have customers that have implemented it and have not had any problems. Stan Swirhin: What changes does this affect? Ed: The only change is to remove the distance specification TBD and replace it with 25m. **************************************************************************** Presentation 3 SW Link length Measurements over 62.5 uM MM Fiber - Jonathan Thatcher - IBM jonathan_thatcher@VNET.IBM.COM Presentation goal was to demonstrate distance requirements verses link performance using existing parts and fiber. Currently sensitivity is relevant but jitter is not limiting item. Steve Swanson has fiber characterization of fiber used in this test. Found that several optical attenuators used in the test had a 50 micron stub which improved system performance. Link configuration is shown in the handout. 5 different cables. Conclusions: Deterministic Jitter may have had an effect. Need to move some of these results to the jitter working group in the EIA/TIA. Some results indicate that the numbers in the current work may be incorrect. Discussion: Shelto: What do you propose? That the Jitter study group start over? Jonathan - No but we should move this work to the Jitter study group. ?: This indicates that the results are better than previously presented IBM results (longer distance achievable). Why? Jonathan: The sensitivity performed better due to using a lower bandwidth receiver which reduced the input noise increasing the SNR. Del: Your graph has 6 traces but only 5 legends. Which legend goes to which? Jonathan: In order from left to right are 8m , 298m, 422m, 573m, 711m, 835m Notice that the DJ is worse at high power due to receiver saturation and the RJ is worse at low power therefore as the link length increased more and more of the Jitter is due to the RJ component. Dave Smith: How are measuring the Random Jitter? RJ measurements are extremely difficult? Ben Spieser: What is the measurement error for these results? Jonathan: I don't know. Shelto: Probes on a scope are typically not linear how did you account for that ? Jonathan: Don't know Dave S; What type of scope? Jonathan: TEK11801 David C: Do you have results of the SW laser using a .85 rms laser Jonathan; No Paul Kolesar: Could the jitter difference that you are seeing be due to Mode Partition Noise or Chirp? Jonathan: Used the same test conditions on each length. Paul: Yes but different lengths would contribute. Dave Smith: MPN will show up as jitter at a distance. You could measure the partition of the test laser and determine the MPN and compare it to the jitter measured to see if that is the additional component. Steve Swanson: The source and fiber were not worst case, how do you expect worst case to work? Jonathan: Theory on jitter is not complete and it is hard to find worst case fiber to test on. Our conclusion is that you can burden the receiver and receiver manufacturer with the jitter penalty. 300 meters shouldn't be a problem. **************************************************************************** Presentation 4 1300 nm Budget for Both SMF and MMF - Ron Soderstrom - IBM rons@vnet.ibm.com Presentation compared current proposed standard to the actual expected launch power of LWL into MMF if the power specifications for MMF and SMF are the same. Recommended that the SMF launch power be the same as for FC in order to leverage FC parts. Bill Reysen and Ron agreed that there is about a 5 db increase in the launch power going into a MMF. Discussion: Paul Kolesar: Will adding 5 db to the upper power limit in MMF still be eye safe. Ron: Yes due to the NA of current laser technology. ?: Using a fiber stub it would be difficult to insure that if the stub became dirty that the link would work. Musk: Same as a fiber to fiber interface --- easy to clean. Ron: Can't clean the stub Musk: Same can be said about a buried wall socket. Dan K: You can take apart a buried wall socket and clean it you can't take apart an optical subassy. Pat G: I would like to see 1 part for all standard but don't like the additional 5 db. Don't want to have to support +2 db at the receiver. Stan S; Concerned about the dynamic range and sensitivity. Current Vitesse part does not spec +2 db capability. Jonathan: Actual testing of the Vitesse part shows that it will handle the +2db Pat G: We could lower both the launch and receive power. Stan: I agree Ron: A stub into multimode fiber can cause problems Dave S: How will index matching be handled for the stub? Del: A stub will lower the increase to around 3 to 3.5 db increase in MMF Musk: you don't strip all the cladding modes but you still see a decrease in power Dave S: How much loss Del: We are not specifying a stub there is no requirement for anyone to use a stub. Ron: Yes but if not implemented and power budget doesn't reflect difference in launch power for SMF and MMF then it could cause problems Pat G: How many will really use a SM laser over MMF? Ron: No clear answer. The desire was for 1 LWL part to be capable of both MMF and SMF. Customers will use SWL over MMF and LWL over SMF for cost since SWL are less expensive. Shelto: LWL cost could be the same as SWL costs. John B: Then I can expect the you to match any SWL quotes I get? Ron: I've heard that for 10 years now. Dave C: Campus backbone user will use LWL over MMF since a large number of campus backbone links are greater than 400 m Dave S: Yes but EIA/TIA work on fiber bandwidth may address how to accomplish these links using SWL technology. Recommendation was to split out SMF and MMF launch specifications. **************************************************************************** Presentation 5 Joint proposal on 1300 nm Optical budgets. Bill Reysen - Amp bhreysen@amp.com Presentation was a joint proposal by Siemans, HP, Sumitomo, and Amp to avoid an increase in maximum receiver input power due to concerns about input saturation power. Proposed changing the transmit power , to use the Hanson / Cunningham model for determining link distance and to propose changing the Laser Rin spec to -122 db. This is more in line with SONET based components instead of FC based components. Discussion: Pat G: Sonet components are more expensive components. Also FC parts allow 15 km links Bill: Ethernet does not require a 15 km link the requirement is for 3 km Paul: Sonet specs also match ATM specs Bill: -20 dbm sensitivity is achievable but -3 dbm currently saturates many devices. Don't want to see and increase in launch power. ?: what is the limiting part Bill: Market availability of preamp saturate at 1 ma, @ -3dbm the current is .9 ma. If we go to a 3.3 volt solution the problem becomes worse Ron: Does the spot size matter? Bill Yes Ron: We don't see this problem using an MSM Pat G; Power density would still be important. Dave S: Internal field charge would be more important that field density. Density can be designed out. Stan: Sure this is not a hard stop but a design issue Bill: I agree Stan: How do we spec different conditions on different fibers without opening the door to two LWL solutions. Bill: Explicitly state that a LWL solution has to meet both launch conditions Jonathan: Editorial wording can make this clear. Should already be included since that was the intent. Dan K: Current parts show a max. of -2.3 dbm Bill: For Amp this is an alignment issue. Current parts are not aligned to a -3 dbm window. This is a small change. Pat G: With the difference in launch power why not accept 2 separate LWL parts for different applications Jonathan: That question was asked of the IEEE body and the message was clear that they wanted 1 part. Stan: Does the RIN spec need to change? Bill: -117 db is sufficient Del: I thing changing the RIN would be beneficial **************************************************************************** Presentation 6 Proposed worst case link model for optical physical media dependent specification development - David Cunningham - HP dgc@hplb.hpl.hp.com Presentation was a proposal to develop an accurate analytical model for laser based multimode fiber links. Included a proposed model in spreadsheet form that would allow worst case modeling of fiber links. Used Del Hanson*s LED based spreadsheet as a starting point Discussion: Paul Kolesar: Eye full open occurs at .8Tc (10-90) instead of .9Tc? David: No, I will verify. Paul: Showing ISI only or total penalty Dave: Most is either ISI or MPN Paul: Why ( How) did you choose ERF transitions as the basis for the spreadsheet. Dave: It uses Gimlett as the basis and assumes that you are using a receiver that is not shaping the pulse. Pat: If you used a trapezoidal pulse you pick up some room Dave: You pick up some ISI but difficult to do. Typical is a Guassian response Pat: What if you shape at the receiver? Dave: If you use equalization you can expect to introduce noise **************************************************************************** Presentation 7 Link Lengths for 850 nm and 1300 nm optical PMDs with all link penalties - Del Hanson - HP del_hanson@hp.com Presentation defined current GbE Link length analysis and attempted to develop a unified MMF interface specification methodology Discussion: Steve S: The numbers used for 50 um fiber do not represent worst case 50 um fiber but uses worst case 62.5 um fiber instead Del: Will show that later but correct using a common number for both fibers. Steve: can you make the spreadsheet available for us to examine Del: Yes send request to me. **************************************************************************** Presentation 8 A manufacturable optical standard for Gigabit ethernet SWL transceivers - Pat Gilliland - Methode Presentation focused on reducing the cost of the transceiver by selecting the lowest cost implementation of piece parts. The main focus was to raise the receive power to -14 dbm , launch power at -8 dbm with a 6 db link budget. Discussion: Dave S: It looks like the major issue you have with current levels is on of cross talk between the transmit and receive side, what kind of isolation are you using between your transmit and receive sides Pat: Looking at a 1x9 plastic housing Dave: It is important to prevent cross talk but don't see that shielding is necessary Del: I agree, Don't think shielding is necessary and I don't think that we need to back off on the receiver sensitivity either. Dave: Sounds like you are attempting to use a separately packaged pin. Pat: Exactly, a discrete pin diode and preamp solution isn't as expensive to purchase as a pin + preamp solution. Dave: Then it is not just an issue of cross talk, by going to a discrete solution you expose the most sensitive node to external noise Pat: If you consider it to be a problem here then it should be a problem in existing protocols and implementations Ron: Do you feel that 6 dbm is sufficient to meet the distance requirements Pat: Yes and I think 6 dbm over spec's the requirement ?: Do you have any imperical data to support that? Pat: No but I think that there has not been enough work don to show performance capabilities. Ed Chang of Unisys has some performance data, perhaps he should be invited in to present it. Del: Is the histogram in your hand out done over temperature? Pat: No John: Where these devices sorted or screened prior to the histogram? This is the type of spread I would expect after a incoming sort. Pat: No Not really Jonathan: This could be looked at differently, Why do you over design you transmitter in order to achieve a lower cost receiver. Pat: If you are purchasing CD lasers then you already have to do a screen. Alignment to insure a transmit power window is easier to perform. John: Then you are doing a screen prior to testing. Stan: How do you justify a 6 dbm link budget and meet the target distance requirements? Pat: What*s to reconcile is the difference between Del*s link budget and other available models Stan: Del*s indicates that 6 dbm is not sufficient Dave S: Actually there is fairly good correlation between Del*s and ours (Honeywell's) for ATM. I don't feel comfortable with a 6 db budget. Pat: I don't think that there is enough data to support the accuracy of the model. Dave C: Our data shows results from typical components and they tend to support the theory. Dave S: I would be concerned with slope efficiency and bias threshold points due to aging would make it difficult to hold the 6 dbm over the life of the product. Pat: You would need a more complex driver to compensate Del: Current links in the field work but that is not the way IEEE specifies a standard. IEEE specifies absolute worst case. Pat: I think we do the user a disservice and have over specified the requirements ?: Will all worst case conditions occur simultaneously or do you think all degradation will be additive. Should we be specifying the requirements based upon a probability or RMS adding of the power penalties? Pat: I don't think we should be using additive worst case. Ron: Range of 2 - 2.5 dbm for a launch power is extremely tight. To hold that I will need to go to a more expensive lens and housing. Pat Sure but that is the trade off between that and a more expensive Pin + preamp. Dave S: I have a basic concern with restricting the launch power. With the wider power range I can control the power with an open loop controller, I can use and inexpensive plastic lens, as an optical source manufacturer I want to insure that I can use the entire population of lasers. This proposal will increase the overall cost. **************************************************************************** Presentation 9 Modal Noise Measurement Technique from TIA/EIA Group - Ron Soderstrom - IBM rons@vnet.ibm.com Presentation was a updated status report of the history and current status of the modal noise task group in the EIA/TIA. Reported the work that has been done and is planned for the MNTMG and when the work is expected to be completed. Discussion: Steve S.: Similar efforts have been initiated in the IEC standards body. IEEE is an international standard and prefers to reference other international standards. Have you considered submitting your work to the IEC for standardization? Ron: Don't know what the process is to do that. Dave S: Not sure that the current work of the group is to a point where they are comfortable dumping it on another committee. Steve S: All you need to do is submit it there isn't a lot of other requirements Shelto: The biggest change would be restructuring it to meet the IEC format. **************************************************************************** Presentation 10 TR41.8.1 Liaison Report - Cris DiMinico - Digital Presentation was a review of the current TR41.8.1 activities. Discussion: ?: When will the -B document be available? Cris: In the September time frame and it will be breaking out copper and fiber portions An additional goal is to harmonize the 11801 work with EIA/TIA 568 Steve S: This will include structured cable , zoned cable, and 50 um fiber. Cris: True but BICSI (sp) hammered the 50 um fiber issue. **************************************************************************** Presentation 11 Modal Noise: 1300nm over 50/125 and 62.5/125 GI MMF - Daniel Kuchta - IBM Presentation was the results of Modal noise using LWL and both 50 and 62.5 um fibers. Concluded that 1300 nm on 50 um fiber MN penalty is too small Discussion: Dave C: How was MSL induced? Dan: Fusion splice with a center defect with an induced .4 db loss. Dave C: .4 is larger than the allowable loss for a fusion splice How did you form such a bad splice? The manufactures that we have tested have never had a loss greater that .38. Today*s splicing technology will not allow that poor of a splice. Ron: The spec allows a splice to have .5 db Dave C: No the spec for a splice is .3 db ?: What is the depth of modulation of the laser used in this testing? Dan: greater than 10 db Dave C: What was the coherence and spectral width of the laser that you used? Dan: Don't have the coherence or spectral width but can show that later. Dave C: What were the details of the launch condition Dan: Category 5 launch condition with good coupling Dave C: I've never seen this kind of results for a cat 5 launch Dan: We found if trivial to put together links that would fail using 50 um and LWL ?: Were the loss conditions (MSL) measured with a laser or an LED Dan: Laser ?: With this loss over connectors with a laser, then the overfill condition would exceed acceptable connector losses as specified in the connector specification. Dave C: Again, not enough details on how measurements where generated. Using a rigorous method we did not see this kind of performance. Dan: With the laser we used it was easy to generate modal noise floors with both center line defects and fusion splice fibers Dave C: Isn't that true for both long and short wavelength lasers? Jonathan: Does this mean that it has to be specified for both LWL and SWL? Dan: No, short wavelength has a lower coherence Frank: Who were the laser manufacturers? Dan: I don't want to name vendor names but they were Japanese manufactures Frank: Without the details of the experiment we cannot reproduce your findings. Dan: I don't want to say manufacturer and model number but the performance was typical of LWL available Dave C: Serial HIPPI uses 1300 in 62.5 and 50 um fiber and don't see any of these problems I don't see that a 3 dbm MN penalty is justified. Dan: True but this is a worst case calculation. IEEE doesn't spec to nominal or typical numbers. Dave C: But I can't verify your results because I can't reproduce your experiment based on the details you have provided. Dan: I think the details are sufficient to reproduce the results if you want to. Stan: What are your recommendations for LWL? Dan: Specify a cat 3 or cat 4 launch for 50 um fiber and specify a 3 db MN penalty for 62.5 um **************************************************************************** Presentation 12 Technical presentation to IEEE 802.3z Gigabit Ethernet working group - Dave Smith - Honeywell - dsmith@micro.honeywell.com Presentation concentrated on Modal noise penalties for both SWL and LWL over both 50 and 62.5 um fiber. Highlighted a potential concern with using severely underfilled launch conditions and LWL over 50 um fiber. Discussion: Ron: Was the launch conditions shown (slide 1) a typical launch or a single mode launch? Dave S: Typical Ron: Would you expect SML using a stub to perform better or worse? Dave S: Shown later in the presentation but I would expect it to be worse. Dave S: The problem is that because of the statistics it is possible for the noise problem to get into a poor performance region and stay there. Dave C: Why wouldn't it change? Changes are occurring rapidly due to a number of parameters in a real world situation. Dave S: Some drifts are slow and stable. Some are not, my concern is that in a controlled environment such as a box or a rack that the environment could be extremely stable. When the slow drift occurs into a poor operated region this could dwell for an extended period. ... Discussion between Dave S. and Dave C faster than I can write ..... Dave C: I can't agree without going over your numbers. Dave S: But this uses currently existing theory Dave C: Lets get together and agree on a set of numbers. Dave S: I think that is reasonable . Jonathan: What are your recommendations Dave S: I think we need to specify the mode fill. My concern is for a proposal I saw using a SMF stub into MMF with LWL Steve: Isn't this being worked on in EIA/TIA Dave S: Not in the MNTMG **************************************************************************** Presentation 13: High Bandwidth Fiber - Dan Kuchta - IBM Presentation requested that we specify an additional fiber line based around a 62.5 um fiber optimized around 850 nm such as the Alcoa Fujijura 800 MHz km bandwidth fiber. Discussion: Shelto: High bandwidth is a misnomer because it is not high bandwidth for 1300 nm , it should be called 850 nm optimized Dan: Sure just like the current specification is around 1300 nm optimized fiber. Paul: I agree with the principal but would prefer to see a graph that equates distance to fiber bandwidth Frank: You already have a high bandwidth fiber .... its called 50 um Dan: Yes but there is a perception that fiber needs to be 62.5 um **************************************************************************** Presentation 14: Optional signal definitions - Jonathan Thatcher - IBM Presentation focused on 3 optional signals that were put in by the editor to determine which should be included and which should be excluded. The signals were signal_detect, laser_disable, and fault Discussion: Del: Who should be making this decision? Jonathan: It is in our clause, we should make it. Del: Does anyone else care? Does it effect anyone else's clauses? Jonathan: I don't think it effects any other group. Dave C: Signal detect is important but needs to clearly state its function Del: Signal detect does not indicate 10 ^-12 BER **************************************************************************** Presentation 15 Integration of FC Jitter working group technical report into 802.3z - Jonathan Thatcher - IBM Gave an overview of the current status of the FC Jitter working group and timing for its inclusion into the draft standard for IEEE Discussion: Jonathan: Multiple test methods are proposed but to my knowledge none can be easily performed. Stan: Do you have a recommendation for which method we should use? Jonathan: No **************************************************************************** Presentation 16 GMII Electrical Specification - Dave Fifield - National Semiconductor fifielf@lan.nsc.com Presentation of current proposed GMII electrical specification Discussion: Jonathan: Is the capacitance at the MII the correct value. Dave: This is what is currently specified in existing chipsets Shelto: You don't show a signal_detect definition Dave: This is the GMII interface, not the PMA PMD interface Koleasr: Why do we need phy definition pins? Dave: I don't know ?: What are they used for at 100 mb/s? Dave: autonegotiation and station management ?: Are these utilized at a Gb/s and how would they be implemented? Dave: Using registers. Shelto: Too many phy types could be defined realistically Dave: Then lets leave it out. **************************************************************************** Presentation 17 GMII Timing update - Asif Igbal - Berkeley Networks asif.igbal@berkeleynet.com Presentation of current timing requirements for Mac to serdes timing interface. Discussion: Assumes background of Vancouver presentation Previous proposed that clock work equally well for both copper and fiber allows unknown phase relationship so long as clock traces match ( source synchronous clocking) Pat: relationship of setup and hold time, why is it symmetric? Asif: We used the 10 b spec but the MAC group voted to change it to a hold of 1.0 and a setup of 2.0 instead of 1.5 and 1.5 **************************************************************************** Presentation 18 All we have is 8 ns! Mac and serdes timing budget - Haluk Aytak -HP haluk_aytac@hp.com Presentation developed the timing budget for the serdes mac interface Discussion: Pat G: So the problem seems to be that there is not a mac vendor who has a defined delay through the mac? Haluk: Yes if the would specify the delay then we could include it. Asif: The problem is that most users don't buy a mac they use a mac core in their implementation asic. The functionality and mac are considered more of a systems design while the serdes is considered part of the phy **************************************************************************** Presentation 19 LWL measurement results - Shelto Van Dorn - Siemans { I don't have a copy of the presentation, Shelto didn't distribute any copies. Can't list presentation conclusions} Presentation basically showed results of LWL launches into multimode fiber that showed very poor eye patterns and may not meet the stated requirements for LWL in 802.3z when swapping from a cat 3 vs cat 4 vs cat 5 launch condition. Discussion: Pat: Can you give more details on the launch conditions? Shelto: Not at this time. Dave S: Did you measure the bandwidth of the fiber using a laser while performing these experiments? Shelto; No Dave S: What were the BER performance for the cat 4 launch that shows such a poor eye diagram? Shelto: No Dave S: Concerned about why the eye is so bad for the launch condition. This doesn't meet the theory explained in Del*s model or the work done in the EIA/TIA group. Dave C: Can you provide index profiles for the fiber that you used? Shelto: No now but we can get that information Del: What was the fiber bandwidth of the fiber used? Shelto: Specified as 500 MHz * km but not measured Bill: Urge you test this fiber using both long and short wave devices. **************************************************************************** This concluded the technical presentations. Jonathan presented a list of motions that he would like to see addressed based upon the presentations given. The goal stated was to eliminate as many of the TBD and target specifications as possible and to replace them with hard numbers. Due to the size of this mailing the motions will be included in a second email. **************************************************************************** Track III - Optical and Short Haul Copper, continuted Motion Mania **************************************************************************** Motion 1 - Technical (75%) Direct the editor to add subclause for RIN test measurements as described in FC Moved Shelto Van Dorn Sec: Del Hanson Discussion: None For 24 Opp 0 Abs 1 Motion Passed **************************************************************************** Motion 2 - Technical (75%) "Signal" should be made optional. If not implemented, it must be default to the "signal received" state Moved Shelto Van Dorn Sec: Norm Harris Discussion: Shelto: If we make this a mandatory signal then we must define it. Del: Also this is not tied to what the functional definition, this includes an optional signal but does not define it's polarity or functionality. Bill: But doesn't this imply that it will be defined? Jonathan: That is a different motion. Currently we are deciding if the signal needs to be included or not. For 25 Opp 0 Abs 5 Motion Passed **************************************************************************** Motion 3 - Technical (75%) "Signal" should be interpreted as "Loss of signal" consistent with fiber channel implementations. Moved Norm Harris Sec: Bob D. Discussion: ?: Loss of signal or Loss of signal bar? Norm: Loss of signal bar ?: So a high logic level would indicate ? Norm: A high logic level would indicate signal was present Jonathan: Are you sure that is the polarity you mean? Norm: I think so. A rousing discussion of active high vs active low ensued leading to Pat I propose we table the motion until we can decide how to define the polarity and functionality of the signal. Jonathan: Friendly amendment to table until the march plenary Pat: Accepted Motion to Table the current motion until the march meeting Moved: Pat Gilliland Sec: Jonathan Thatcher For 22 Opp 6 Abs 1 Motion Passed **************************************************************************** Motion 4 - Technical (75%) Remove Transmit Disable text in draft 1 Moved Shelto Van Dorn Sec: Pat Gilliland Discussion: This will remove any possibility of OFC in Gigabit Ethernet. For 13 Opp 7 Abs 10 Motion Failed Motion to include transmit disable per text in draft 1 as an optional signal Moved Ed Grivna Sec. Tom P. For 11 Opp 13 Abs 5 Motion Failed Text will be removed since it was not an approved draft text. **************************************************************************** Motion 5 - Technical (75%) Remove Fault Status text in draft 1 Moved Shelto Van Dorn Sec: Pat Gilliland Discussion: None For 15 Opp 4 Abs 3 Motion Passed **************************************************************************** Motion 6 - Technical (75%) Move that the group adopt the model presented by Cunningham/Hanson as the basis for calculating link distances for LW and SW optical PMDs Moved Bill Reysen Sec: David Cunningham Discussion: Does this fix the parameters used in the model? No, this is to fix the form of what is to be included. Discussions on the actual parameters and requirements can still be changed and amended. David C will publish the basis and will put the spreadsheets on the web site. For 37 Opp 3 Abs 4 Motion Passed **************************************************************************** Motion 7 - Technical (75%) Modal Noise Penalty 62.5 50 SWL 1/2 db 1 db LWL 1 1/5 db 2 db We propose that the above values be included in the link budgets in the standard draft for modal noise penalty Moved Dave Cunningham Sec: Dave Smith Discussion: Jonathan: Is this for inclusion in the model of in the standard Dave C: Inclusion in the standard Ron: Already in the standard for SWL Paul: Worried about tying down LWL numbers based on current presentation material Del: This is needed to lock down the power budget Dave S: EIA/TIA will verify and define the LWL modal noise penalties. We can revisit this and correct it if the findings are different Pat: Should we send it to a subcommittee to verify that numbers. Dave S: Tabling this motion will keep us from being able to agree on the link budget. This could push the fiber specification out until the conclusion of the EIA/TIA work which could delay us for over a year. Pat: Object to making this a normative requirement if there is not a defined method for measuring the numbers. Motion to send to subcommittee Moved: Vince Melendy Sec: Pat Gilliland For 3 Opp 26 Abs 0 Motion to send to subcommitte Failed Pat: propose a friendly amendment to include these numbers as informative text rather than normative. Accepted new motion reads Motion We propose that the above values be included in the link budgets as informative text in the standard draft for modal noise penalty For 33 Opp 0 Abs 0 Motion Passed **************************************************************************** Motion 8 - Technical (75%) Adopt the methode proposal for the SX optical power budget Moved Pat Gilliland Sec: Vince Melendy Discussion: Dave: I don't think column 3 (Methode proposal) is consistant with manufacturability Pat: I think that they are a fair compromise Del: Agree that column 3 would be more expensive Bill: I don't think the -5db @ 770 is required Jonathan: IBM concurs with Dave and Del For 3 Opp 20 Abs 6 Motion Fails **************************************************************************** Motion 9- Technical (75%) Adopt the HP proposal for the SX optical power budget Moved Dan Brown Sec: Del Hanson Discussion: Jonathan: Feels that 0 db should be used for the receiver max power limit in case the eye safety limit increases due to harmonization of the international and US standards Dave S: I agree. If the receiver power is at 0db then if the power is increased as expected then modules in the field would still be able to operate with new models that can take advantage of the higher transmit power requirements. Del: We can live with 0 dbm if that is what is decided. This increases our dynamic range. Paul: Why does it matter if it doesn't increase the performance (distance) capabilities of the link Jonathan: Allows a relaxation of the manufacturing procedures, lower cost drivers, larger population of sources. Pat: Does this mean we can transmit 0 dbm Jonathan: Not currently but possible in the future. For 10 Opp 11 Abs 7 Motion Fails **************************************************************************** Motion 10 - Technical (75%) Adopt the current proposal for the SX optical power budget Moved Ron Soderstrom Sec: Ed Grivna Discussion: None For 21 Opp 3 Abs 7 Motion Passed **************************************************************************** Motion 11 - Technical (75%) Adopt the amp power budget for the LX optical power budget Moved Bill Reysen Sec: Shelto Van Dorn Discussion: None For 18 Opp 5 Abs 3 Motion Passed **************************************************************************** Motion 12 - Technical (75%) Move that the line for launch power @ 770 nm and 850 nm be removed and replaced with a note stating "Lesser of IEC class 1 or RCV max receive power" Moved Bill Reysen Sec: Ron Soderstrom Discussion: For 30 Opp 0 Abs 0 Motion Passes **************************************************************************** Motion 13 - Technical (75%) Move that the group adopt a RIN specification of -122 db Hz for the LW PMD Moved Musk Sec: Paul Pace Discussion: Jonathan: I don't think our lasers can meet this requirement, I would like to have some time to verify our capability Motion to table until next meeting failed. For 13 Opp 6 Abs 5 Motion Fails **************************************************************************** Motion 14 - Technical (75%) Moton to form a subcommittee to specify fiber requirements and to prepare a motion for the march meeting to remove the TBDs in the current draft. Subcommittee members: Steve Swanson (Corning) ; Paul Kolesar ( Lucent ) ; Todd Hudson (Siecor) ; Dan Kuchta ( IBM) Moved Shelto Van Dorn Sec: Steve Swanson Discussion: For 24 Opp 0 Abs 0 Motion Passed **************************************************************************** Motion 15 - Technical (75%) Designate a subcommittee to create a first pass of the essential timing specifications for clause 38 and 39 and the PMA portion of 36. Put these targets into the next draft. Subcommittee: Haluk (HP) Jonathan Thatcher ( IBM) John Bowerman (Honeywell), Ed Grivna ( Cypress) Moved Paul Kolesar Sec: Ed Grivna Discussion: For 18 Opp 0 Abs 1 Motion Passed **************************************************************************** Motion 16 - Technical (75%) Direct the editor to include a subclause based on work in cls 23.9. Make consistent with remainder of clause. Moved Ed Grivna Sec: Shelto Van Dorn Discussion: For 17 Opp 0 Abs 3 Motion Passed **************************************************************************** Motion 17 - Technical (75%) Adopt the receive eye (FIGURE 39.4) and interface length of 25m Moved Ed Grivna Sec: Shelto Van Dorn Discussion: For 17 Opp 0 Abs 6 Motion Passed **************************************************************************** Motion 18 - Procedural (50%) Appoint a subcommittee to investigate, solve and bring the solution to the march meeting on characteristic impedance. Solution should include complete text ready to add to draft along with an accompanying motion. This be documented on the reflector at least two weeks prior to the meeting Subcommittee: Ed Grivna; Bill ham; Henriecus Koeman; Haluk Moved Shelto Van Dorn Sec: David Cunningham Discussion: For 15 Opp 0 Abs 5 Motion Passed **************************************************************************** Motion 19 - Technical (75%) We should not include the table suggested by IBM for High Bandwidth 62.5 um fiber at this time Moved Pat Gilliland Sec: Ed Grivna Motion to table indefinitely Moved Paul Kolesar Sec Bill Reysen Discussion: For 24 Opp 0 Abs 4 Motion Tabled **************************************************************************** Motion 20 - Technical (75%) Corning moves that the IEEE 802.3z PMA/PMD task group chair submit a liason letter to the chair of the TIA/ TR 41.8.1 updating the TR41.8.1 of the current fiber requirements in the draft gigabit ethernet standard. Specifically we should provide a copy of the draft and an application map noting new requirements to multimode fiber that can be used for updating TIA 568A Moved Steve Swanson Sec: John Bowerman Discussion: For 21 Opp 0 Abs 1 Motion Passed **************************************************************************** John Bowerman Honeywell jbowerma@micro.honeywell.com **************************************************************************** 802.3z Closing Session Wednesday January 29, 1996 San Diego, CA 1:30 pm Steve Haddock's Sub-taskforce Report ==================================== A: Draft D2 will say nothing about buffered distributors. Text was placed in draft D1 on the basis of editorial license. The current text will be withdrawn on the same editorial license. C: How was the break-out session on late collisions resolved? A: It was decided that the originating MAC will not re- transmit frames on late collision. C: Does this decision affect 10/100? A: No. It will only be done for 1000 Mb/s. C: Don't we need a motion for this? A: This is a sub-taskforce report. C: Do we still JAM with VOID? A: I would like to but it is not important to JAM with VOID. The JAM pattern remains an open issue. Bob Grow's Sub-taskforce Report =============================== A: Two motions were passed. An issue list was built. Jonathan Thatcher's Sub-taskforce Report ======================================== A: 22 - 23 motions were made. The majority of the motions passed; a couple didn't. Only a couple of the motions impact the upper layers such as GMII. A significant event was that HP put together a new version of the spreadsheet with updated models. Consensus was reach on the new models. The new models indicate that the fiber PMD is meeting the distance targets. More than half of the TBDs were cleared from the 1000 Base-X PMD clauses. Track III kicked off a couple of study groups. One study group is looking at jitter budget allocation. C: Are the fiber channel jitter study group really going to vote on that TR next week? A: Yes. Some work is required to incorporate the work into GE. C: Do you want to review motions from your group? A: Yes, but the track III secretary is not here right now. Geoff Thomson's Liaison Report ============================== Last week's meeting saw significant discussion on the frame size impact, mostly at the low end. 802.1 drafted a liaison statement to 802.3 on this issue. It reads: (Quote) Draft liaison statement from 802.1 to 802.3 generated at Westlake village interim meeting. This statement is expected to be finalized at the March Plenary. It was the intent that the draft of this statement be presented at the P802.3z meeting in San Diego 1/27-29/97. DRAFT - 802.1 is engaged in work (P802.1Q) on VLANs, which specifies use of "tagged" MAC frames: i.e., frames that have additional octets of link-layer information inserted into an original (untagged) frame. - This work is likely to reach standardization. - The tag size specified in the initial version of the standard is very likely to be 4 octets on CSMA/CD MAC. - Primary use for tagged frames is expected to be for inter- switch backbone traffic or for other aggregated traffic on high-speed links. - Important secondary use for tagged frames is for traffic to and from backbone-attached server systems. - Further, novel, uses for tagged frames are expected to be developed to take advantage of VLAN capabilities. - Usage of VLAN, and hence of tagged frames, is expected to become pervasive in future, switched, LAN configurations. - Possible future work has been considered that would specify alternative tag formats; it is likely that such tags would be longer than 4 octets (8 octets?) - It is not expected that any use will be made of nested, multiple tags. - P802.1Q provides for use of untagged frames, by existing LAN end stations; P802.1Q bridges will add tags to frames received from such stations, and remove tags from frames transmitted (over final hop(s)) to such stations. - Very large amounts of installed software generate full- size (1500 octet) MAC user data; most (at least, much) of this software cannot be expected to change in this respect. - 802.3 are asked to consider what possibilities exist for future support of “baby giant” frames, conveying 1500 octets of MAC user data plus the additional Link-Layer tagging information, as outlined. (End Quote) George Eisler's Sub-taskforce Report ==================================== A: Track II worked on the 1000 Base-T line code and structural design. Track II also worked on the 5 criteria and the PAR. George circulated the PAR form. A: Transistor count estimates were presented for each of the proposals. Proposals used 1 - 1.5 million transistors and had a power dissipation of 4 - 5 Watts. George presented the 1000 Base-T schedule as: Line code closed: Jul 97 Draft: Sep 97 Contingent approval for WG ballot: Nov 97 Contingent LMSC ballot: Mar 98 Standard Board: Jul 98 Rich Taborek's Sub-taskforce Report =================================== Rich showed the presentation agenda that was used. He then reviewed his presentation "PCS Issues". ================ | New Business | ================ Motion 1: ========= Move 802.3z accept the 1000 Base-T PAR and 5 criteria as amended and direct the chair of 802.3 to: a) forward by Feb 6 to the IEEE standards office for inclusion in the Feb 7 NESCOM package, b) forward to the IEEE 802 Executive Committee by Feb 6 to meet the 30-day review requirement, c) present to 802.3 for final review and approval at the March '97 plenary. Moved: Mick, Seconded: Payne There was no discussion. Vote on motion - Yes: , No: , Abstain: The chair interrupted the vote. Howard did not accept that there was no discussion. C: Geoff suggested that some external references in section 10b needed to be added or changed. This change was accepted as a friendly amendment. C: Section 5 should say yes instead of no. This project will be a supplement to 802.3z 1995. This change was accepted as a friendly amendment. Vote on motion - Yes: 72, No: 0, Abstain: 6 Motion is classified as technical. Motion passes. Motion 2, Technical: ==================== Form a sub-taskforce within 802.3z to draft the required text to support gigabit management. Use the same approach as 100 Mb/s management. Moved: Law, Seconded: Crayford C: Have resources been identified to staff this work? A: A second motion is planned to address this. The two motions can be combined. Amendments were made to the motion to make David Law sub- taskforce chair. David felt that it was inappropriate to move to appoint himself. David Law withdrew the motion. The amended motion follows. Motion 3, Technical: ==================== Form a sub-taskforce within 802.3z to draft the required text to support gigabit management. Use the same approach as 100 Mb/s management. Appoint David Law as management sub- taskforce chair. Appoint Sumesh Kaul as management sub- taskforce editor. Moved: Veloskin, Seconded: Crayford There was no discussion. Vote on the motion - Yes: 74, No: 0, Abstain: 6 Motion passes. Motion 4: ========= Adopt 802.3x flow control as mandatory for 802.3z. Moved: Hendel, Seconded: Muller C: Is this motion intended to apply to full-duplex operation only? A: Full-duplex operation is implicit in 802.3x flow control. C: GE wouldn't want to be committed to new features that might be added later to MAC Control. A: The motion limits the scope to flow control. C: I propose that you add 802.3ab in addition to 802.3z. This was accepted as a friendly amendment. C: I propose that you amend to add the following: "with extensions for asymmetric flow control". A: I cannot accept that as a friendly amendment. Asymmetric flow control is an open issue which could defeat this motion. C: Asymmetric flow control is required for buffered distributors. The request for amendment was withdrawn. C: Can anyone bring forward models or other information on how 802.3x performs, especially with respect to IP? A: This motion states that pause capability has to be there. It doesn't state that it has to be turned on. C: I interpret mandatory to indicate that you can't turn it off. C: I propose that you amend to motion to read: "Adopt 802.3x full-duplex flow control as specified in annex 31b as mandatory for 802.3z and 802.3ab." This was accepted as a friendly amendment. C: If this motion passes, only one auto-negotiation bit will be needed: asymmetric or symmetric. C: I still believe that this motion can be read as "always have to respond to pause". That is, you can't turn it off. I don't recommend always responding to pause. A: I don't think that you always have to advertise pause receive capability. C: Mandatory is the wrong word. A: Mandatory means to me that pause operation should be implemented so that if you need it, it is available. Note that transmission can be turned off. Turning transmission off is sufficient. Reception should not be turned off. C: I think that the wording is badly broken. I also read this as making full-duplex operation mandatory. The motion was withdrawn. Motion 5, Technical: ==================== That IEEE 802.3z use as the basis for the GMII timing and electrical specification, clause 35: Option C Timing: Haluk Aytac, Nov 96. GMII Electrical and Timing Specification: Asif Iqtal, Nov 96. GMII Timing Update: Asif Iqtal, Jan 97. GMII Electrical Specification: David Fifield, Jan 97. MAC, SERDES Timing Budget, Haluk Aytac, Jan 97. for inclusion is Draft 2. Moved: Fifield; Seconded: Grow A: There is general consensus in the working group that the GMII should look like the PMA service interface. There are some details to work out but these specifications serve as a basis. C: Are all of these presentations consistent with respect to clock direction? A: The intent is to take the timing information, not the clock direction, from these presentations. C: I suggest that the motion be amended to read: "Option C Timing (except clock direction)". The other presentations agree and define the clock direction. This was accepted as a friendly amendment. C: What do these presentations say about the SERDES set-up and hold times. A: 2ns set-up time. 1 ns hold time. C: What is the clock direction? A: Source synchronous. C: Does this motion have the effect of endorsing clause 35 from draft D1? A: No. This motion just adds timing information. C: There is a conflict between these presentations over whether the rising or falling edge of the clock is the active edge. C: When data is latched into the PHY, working solutions can use the falling edge or delay the clock. These two options were presented in Vancouver. In San Diego, the recommendations in my presentation selected driving from the rising clock and latching on the falling clock. C: I would like the specification to allow latching on the positive edge or the negative edge at the option of the vendor. C: Which is the active edge? Isn't it drive rising and sample rising? C: From MAC to PHY, source synchronous clocking is specified driving on the rising edge and sampling on the falling edge. To the SERDES, global synchronous clocking is specified driving on the rising edge and sampling on the rising edge. C: I call the question. The chair asks if anyone objects. Mason objects. Vote to call the question - Yes: 36, No: 1, Abstain: 9 Vote on motion - Yes: 34, No: 13, Abstain: 21 Motion fails. C: Can I make a comment? C: Is it related to the previous motion? C: Yes. C: No. I'm sorry, I cannot allow that. It would be out of order. The motion failed. Motion 6: ========= Upon Loss_of_Sync, link configuration/auto-negotiation shall be restarted. Moved: Chen, Seconded: Tenkins A: I propose this solution instead of the current mechanism of starting a timer. We don't need so many layers of error handling. C: Does this motion mean that sync acquired would restart auto-negotiation. If so, I think that we have this already. A: Yes. However, in the current text it is stated that it starts a timer. C: I think that the earlier motion (in Track I) to adopt the auto-negotiation mechanisms addresses this. C: I agree with your motion conceptually. I am not sure if you specify the exact correct state in the state machine. C: Why was the time-out used in fiber channel? C: Loss of synchronization is not the opposite of synchronization acquired. There is already some hysteresis. C: In the hysteresis, can I still get a C ordered- set across? This thread moved to a private discussion. Vote on the motion - Yes: 39, No: 0, Abstain: 22 The motion was classified as technical. Motion passes. Motion 7: ========= The reception of K characters which are not used shall be treated as the data values they decode to. Moved: Chen, Seconded: Taborek A: As it is currently written, unused K characters received are to be translated to IDLE. The current behavior is to allow future ordered sets to be used in the inter- packet gap. When K characters are translated to IDLE, IDLE removal could take out any future ordered sets used in the IPG. Treating unused K characters as data is easier to implement. A: The motion has another implication. The current specification was intended to convert undefined ordered-sets to IDLE so that they did not generate false carrier. If this motion is passed, use of undefined ordered-sets will trigger false carrier. C: If the unused K characters are translated to data and they occur inside of a packet, they could cause an undetected error. A: Translation to data is easiest to implement. C: Undetected errors would be a bad side effect. C: A frame could pass its CRC check. When unused K characters occur during data, I would rather see them decode to VOID. C: The current state machine reflects the data up to the GMII but does not assert RX_ER. C: What does the current state machine do if the undefined order-set occurs during IDLE? Rich Taborek starts a design inspection. A: I propose that the motion be amended to change "the data values they decode to" to "a decoding error". I accept. C: This leaves no future. If currently undefined ordered- sets are sent from a future machine to this machine, it will break today's machine. A: The allowance is of limited value. C: Be liberal in what you receive. A: The allowance is only available in the inter- packet gap. C: Yes, but that can be good. A: This has implications for a repeater. A repeater might perform IDLE removal. C: Repeaters would ignore undefined order-sets, just as a NIC would. C: I suggest that we move this issue to the PCS sub- taskforce. The motion was withdrawn. Straw Vote ========== The chair, Howard Frazier, held a straw vote to determine how many people would leave in 1 hour, even if there was more business pending. There was no formal count taken. Howard summarized the vote as: quite a few. Howard levied a restriction of 5 minutes per motion. Motion 8: ========= Adopt 802.3x flow control capabilities, as specified in annex 31b, as an integral part of 802.3z and 802.3ab embodiments. Moved: Hendel, Seconded: Muller C: How is this motion above and beyond the objectives? A: This says that 802.3z- and 802.3ab-compliant implementations have to have the capability. C: I call the question. There was no objection to calling the question. Vote on the motion - Yes: 12, No: 12, Abstain: No count was taken of the abstain vote. The chair summarized the count as: lots. The motion was classified as technical. Motion fails. C: Did we just change our objectives? C: No, it was not written to change to objectives. Motion 9: ========= Add jitter tolerance on GTX_CLK to transmit AC specification table 36-7, value TBD. Moved: Sankey, Seconded: Robins. C: I propose to amend the motion to change "jitter tolerance" to "maximum jitter specification". The amendment was accepted as friendly. C: A MAC may not be able to produce a clock with low enough jitter to be useful to the PHY on the medium. A: I expect it to. C: Can we move this to a sub-taskforce? A: No one sub-taskforce has all the expertise required. C: I move to refer this to the GMII sub-taskforce. Seconded by Thirion. The motion to move was judged to be procedural. Vote on the motion to move - Yes: 46, No: 1, Abstain: 7 The motion to move passes. Motion to reconsider ==================== A motion was made to reconsider motion 5. Moved: Lewelling, Seconded: Thirion The motion to reconsider was judged to be procedural. There was no discussion. Vote on the motion to reconsider - Yes: 46, No: 3, Abstain: 9 Motion to reconsider passes. --> Motion 5: C: Why are there two different solutions, one for the GMII and a second, different, solution for the PMD to PMA interface? A: Work is needed to define the clock direction and the active clock edge but this motion just allows something to get written down. Changes can occur later. C: I propose to amend the motion by striking the presentation by Asif, Nov 96. A: I have concerns with that presentation, plus its 5 volt issues. The amendment was accepted as friendly. C: I propose to amend the motion by adding "clk direction and active edge of the clock(s) is a subject for further study". The amendment was accepted as friendly. Vote on the motion - Yes: 35, No: 1, Abstain: 9 The motion is classified as technical. Motion passes. C: What is further study? A: The new information would go in as proposed text not voted in. It would take a further vote to keep the proposed text in the specification. Motion 10: ========== Liaison letter Geoff -> TIA TR-41.8.1 Moved: Thatcher, Seconded: Rauch Some back and forth on the best wording, without closure. C: Track III passed this motion. Is it necessary to consider it here? A: Track III actioned me. This motion actions Geoff Thompson. More back and forth on procedural issues. The motion was withdrawn. Plans for the Next Meeting ========================== Howard Frazier presented. March 10 - 14 : Plenary, Marriot Irvine CA May 14 - 16: East coast. Volunteers? Possible volunteer in Florida. July 7 - 11: 802 Plenary week, Maui Sept: London, 3COM. Probably the week of the 8th. Oct: ??? Motion to approve the minutes from Vancouver. The motion passes by acclamation. ADJOURN