CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`30.6.1.1 .9 aAutoNegAdvertisedSelectorAbility
`
`ATTRIBUTE
`
`APPROPRIATE SYNTAX:
`
`Same as aAutoNegLocalSelectorAbility
`BEHAVIOUR DEFINED AS:
`
`This GET-SET attribute maps to the Message Selector Field of the Auto—Negotiation Link Code
`Word, defined in clause 28. A SET operation to a value not available in
`aAutoNegLocalSelectorAbility will be rejected. A successful set operation will result in
`immediate link renegotiation if aAutoNegAdIninState is enabled.
`
`NOTE—This will in every case cause temporary link loss during link renegotiation. If set to a value incom-
`patible with aAutoNegReceivedSelectorAbility, link negotiation will not be successful and will cause per-
`manent link loss.;
`
`30.6.1.1 .1 0 aAutoNegReceivedSelectorAbility
`
`ATTRIBUTE
`
`APPROPRIATE SYNTAX:
`
`Same as aAutoNegLocalSelectorAbility
`BEHAVIOUR DEFINED AS:
`
`Indicates the advertised message transmission ability of the remote hardware. Maps to the Message
`Selector Field of the last received Auto-Negotiation Link Code Word, defined in clause 28.;
`
`30.6.1.2 Auto-Negotiation actions
`
`30.6.1 .2.1 acAutoNegRestartAutoConfig
`
`ATTRIBUTE
`
`APPROPRIATE SYNTAX:
`
`None required
`BEHAVIOUR DEFINED AS:
`
`Forces Auto—Negotiation to begin link renegotiation. Has no effect if Auto-Negotiation signaling
`is disabled;
`
`30.6.1.2.2 acAutoNegAdminControl
`
`ATTRIBUTE
`
`APPROPRIATE SYNTAX:
`
`Same as aAutoNegAdminState
`BEHAVIOUR DEFINED AS:
`
`This action provides a means to turn Auto-Negotiation signaling on or off;
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0351
`
`

`

`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`0352
`
`Aerohive - Exhibit 1025
`0352
`
`

`

`
`
`0353
`
`Aerohive - Exhibit 1025
`0353
`
`

`

`
`
`0354
`
`Aerohive - Exhibit 1025
`0354
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`The signal transmission path characteristics are stated in terms of their maximum delay and their
`characteristic impedance. These values are summarized in table 22A-1.
`
`Table 22A-1—Signal transmission path characteristics
`
`
`
`The driver characteristics specified in 22.4.3, the receiver characteristics specified in 22.4.4, and the
`signal transmission path characteristics specified in table 22A—1 can be applied to the system models
`shown in figure 22A-1 or figure 22A—2. The combination of loads presented in figure 22A—3 cannot be
`adequately driven by an output buffer that meets the driver characteristics specified in 22.4.3 while being
`sampled by an input buffer that meets the receiver characteristics specified in 22.4.4.
`
`To address the system model depicted in figure 22A-3, it is permissible to incorporate an additional
`stage of buffering into path sections A1, A2, D1, and D2, provided that the resulting maximum delay
`characteristic for those path sections does not exceed the value stated in table 22A—1. The delay
`characteristic for transmission path sections A2 and D2 includes an allowance for the delay that results
`from the presence of a lumped capacitive load at the end of the path. For a transmission path section
`with a characteristic impedance Z0, with a lumped capacitive load CL, this delay is nominally ZOCL. In
`the case of a maximum transmission path section impedance of 78 Q with a lumped load of 8 pF, the
`nominal delay is 0.6 ns. Thus the allowable delay for a buffer inserted into transmission path section A2
`or D2 is 4.4 ns.
`
`22A.3 Budget calculation
`
`A recommended timing budget is shown in table 22A—2. This budget assumes that the combined system
`model shown in figure 22A-3 represents a worst case.
`
`Table 22A-2—Round-trip delay budget
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgrd.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0355
`
`

`

`
`
`0356
`
`Aerohive - Exhibit 1025
`0356
`
`

`

`CSMA/CD
`
`IEEE
`Sid 802.3u-1995
`
`22B.2 Romain) and V, | values for operation from 5V :1 0% supply
`
`Referring to figure 22B-1, Rommm) and ROijn) both equal 40 Q, and the values for the V-I points on the
`curve are given in table 22B-1 below for MII drivers that drive rail to rail from a +5 V :i: 10% power
`supply.
`
`Table 223-1—Values for driver output V-l curve (5 V supply)
`
`
`
`22B.3 Room") andV, I values for operation from 3.3 t 0.3V supply
`
`Referring to figure 22B-1, Rommin) and Roumin) both equal 33 Q, and the values for the V—I points on the
`
`curve are given in table 22B-2 below for MII drivers that drive rail to rail from a +3.3 :: 0.3 V power
`supply.
`
`Table 223-2—Values for driver output V-l curve (3.3 V supply)
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stangigrd.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0357
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 226
`
`(informative)
`
`SUPPLEMENT TO 802.3:
`
`Measurement techniques for Mll signal timing characteristics
`
`226.1 Measuring timing characteristics of source terminated signals
`
`The measurement of timing relationships between MII signals at the M11 connector is complicated by
`the use of driver output impedance to control transmission line reflections on point-to-point transmission
`paths passing through the connector. The voltage waveforms on point-to-point transmission paths can be
`different at the MH connector and at the end of the paths. A clean transition (or step) from one logic
`state to the other at the end of a point to point path can appear as two half—steps at the M11 connector.
`
`To eliminate ambiguity as to where on a two half-step state transition to measure timing, all timing
`measurements on point-to-point transmission paths will be at the end of the path. In some cases, an end
`of path must be artificially created.
`
`226.2 Measuring timing characteristics of transmit signals at the Mll
`
`The timing of TX_EN, TX_ER, and TXD<320> relative to TX_CLK at the M11 connector is measured as
`follows.
`
`Use the time base for TX_CLK as a timing reference. Break the TX_CLK path at the M11 connector,
`forcing the TX_CLK point-to—point transmission path to end at the connector. Measure when the rising
`edge of TX_CLK passes through Vih<min) at the M11 connector. Call this time Tclk. Reconnect the
`TX_CLK path at the M11 connector and break the paths of TX_EN, TX_ER, and TXD<3:0> at the MII
`connector, forcing the paths to end at the connector. Measure when TX_EN, TX_ER, and TXD<3:0>
`exit the switching region at the M11 connector. Call these times Ten, Ter, and T<3.0>, respectively.
`
`The timing relationships at the M11 connector for TX_EN, TX_ER, and TXD<3:0> relative to TX_CLK
`are met if (Ten — Talk), (Ter — Talk), (T3 — Tclk), (T2 — Tclk), (T1 — Tong), and (To — Tolk), respectively, meet
`the timing relationships specified in 22.3.1.
`
`226.3 Measuring timing characteristics of receive signals at the Mll
`
`The timing of RX_DV, RX_ER, and RXD<3:0> relative to RX_CLK at the M11 connector is measured
`as follows.
`
`Break the paths of RX_CLK, RX_DV, RX_ER, and RXD<3:0> at the M11 connector, forcing the paths
`to end at the connector. Measure when RX_DV, RX_ER, and RXD<320> exit the switching region at the
`
`M11 connector relative to when the rising edge of RX_CLK passes through meax). Also measure when
`RX_DV, RX_ER, and RXD<3:0> reenter the switching region relative to when the rising edge of
`RX_CLK passes through Vihonin) .
`
`The timing relationships at the M11 connector for RX_DV, RX_ER, and RXD<320> relative to RX_CLK
`are met if the times measured in the previous step meet the timing relationships specified in 22.3.2.
`
`This is an39g'chive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0358
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`220.4 Measuring timing characteristics of MDIO
`
`The MDIO and MDC signal timing characteristics cannot be measured using the techniques defined for
`the transmit and receive signals since MDIO and MDC may connect a single station management entity
`to multiple PHY devices. The MDIO and MDC timing characteristics are measured with a PHY
`connected to the M11 connector. The signal timing characteristics for MDC and MDIO must be met over
`the range of conditions which occur when from one to 32 PHYs are connected to an STA. When 32
`PHYS are connected to an STA, the total capacitance can be as large as 390 pF on MDC, and as large as
`470 pF on MDIO.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0359
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 23A
`
`(normative)
`
`6T code words
`
`SUPPLEMENT TO 802.3:
`
`The leftmost ternary symbol of each 6T Code group shown in table 23A-l (broken into 23A-la and 23A-1b
`for pagination) shall be transmittedfirst. The leftmost nibble of each data octet is the most sigmficant.
`
`Table 23A-1a—1OOBASE-T4 836T code table
`
`Data
`
`octet
`00
`
`01
`
`02
`
`03
`
`04
`
`O5
`
`06
`
`6T code group
`———00+—
`
`o+—-»—o
`
`
`
`
`
`-——0--—O
`
`—O+-~—O
`
`—0+0+—
`
`O+——0+
`
`+—o—o+
`
`Data
`
`octet
`20
`
`21
`
`22
`
`23
`
`24
`
`25
`
`26
`
`6T code group
`OO—++—
`
`——+oo--
`
`
`
`+--—o+—
`
`+-»—O—~
`00+o—»
`
`00+O+—
`
`00—00»
`
`——+++—
`
`Data
`
`octet
`£0
`
`£1
`
`£2
`
`£3
`
`£4
`
`£5
`
`£6
`
`£7
`
`6T code group
`-—O—-OO—
`
`
`
`-»+00—o
`
`—0—O—0
`
`O+--O—O
`
`Data
`
`octet
`60
`
`61
`
`62
`
`63
`
`6T code group
`0—0—-+0
`
`00—--0--
`
`O—O—-O—-
`—OO--O+
`
`—00---»0
`
`
`
`
`
`0+-00— 64
`
`—+0—00
`
`»0-—00
`
`65
`
`66
`
`67
`
`00—0----
`
`0—00-»--
`
`—000
`
`
`
`£8
`
`£9
`
`£A
`
`£13
`
`£c
`
`£3
`
`£7.
`£F
`
`5o
`
`
`0+-—OO
`
`000+00
`
`000—++
`
`OOO+—+
`
`000++—
`
`coo—+0
`
`GOO—0+
`
`68
`
`69
`
`6A
`
`6B
`
`6C
`
`63
`
`63
`6F
`
`70
`
`07
`
`O8
`
`09
`
`0A
`
`OB
`
`0c
`
`03
`
`0:3
`OF
`
`—0+—0+
`
`—+00+—
`
`o—++—o
`
`—+0+—0
`
`-»o—+—o
`
`-»o—o+—
`0—+—0--
`
`—+0—0--
`
`——O——0-—
`
`
`
`27
`
`28
`
`29
`
`2A
`
`2B
`
`2c
`
`23
`
`2:
`2F
`
`30
`
`—o—++o
`
`——0+o--
`
`—O—+0--
`
`0——+o--
`
`0——+-o
`
`——00-——
`
`—0—o--
`
`0——O-—
`
`+—oo—
`
`
`
`—-—-»0
`
`——+
`
`
`
`
`
`+——-o+
`
`+——-»0
`
`
`
`0
`
`
`
`————-O—-
`
`
`
`——+0-——
`
`—-—0-»-
`
`———0———
`
`—-+000
`
`
`
`
`
`
`
`-—--000
`
`»-—000
`
`
`
`00-—000
`
`—0-»000
`
`0—+000
`
`+0—000
`
`0+—000
`
`0—— -+
`
`71
`
`72
`
`73
`
`74
`
`75
`
`76
`
`77
`
`78
`
`000-»—0
`
`000——O—
`»0-——+
`
`-—0—+—
`
`»o-—+—
`
`
`
`
`
`O ——+—
`
`0--——+
`
`»+o+——
`
`
`
`0—-
`
`——
`
`0--»——
`
`10
`
`_.1
`
`:2
`
`.3
`
`:4
`
`:5
`
`_.6
`
`:7
`
`
`
`-»0+——0
`
`-—+0—0—
`
`»0-»—0—
`
`O+——0—
`
`0+-»——0
`
`
`
`»+00——
`
`-O+O——
`
`
`o++0——
`
`31
`
`32
`
`33
`
`34
`
`35
`
`36
`
`37
`
`
`
`0+—— 0
`
`+—0—»0
`
`—O+— O
`
`—0+o—+
`
`0+—+0—
`
`+—0+0—
`
`—o--+0—
`
`51
`
`52
`
`53
`
`54
`
`55
`
`56
`
`57
`
`
`
`_.8
`
`Z9
`
`_A
`
`ZB
`
`__c
`
`__3
`
`
`'7
`1F
`
`
`
`o+—o+—
`
`O+—O—-—
`
`O+—++—
`
`O+—OO-—
`
`0—+00+
`
`0—++--—
`
`O——O—+
`
`0—-0-—
`
`
`
`38
`
`39
`
`3A
`
`3B
`
`3c
`
`3D
`
`3E
`
`3F
`
`—+oo—+
`
`O——-—-—O
`
`
`
`
`
`—+0— 0
`
`+O——-—O
`
`+0—o—+
`
`0—++0—
`
`—+0+0—
`
`+o—+o—
`
`58
`
`59
`
`5A
`
`5B
`
`5c
`
`5D
`
`5E
`
`5F
`
`
`
`--0——
`
`
`
`79
`
`7A
`
`7B
`
`7c
`
`73
`
`7:
`7F
`
`
`
`
`
`—0——-+
`
`——O--»+
`
`——O—-—0
`
`+-—00—
`
`
`
`00+00—
`
`+—- — — — —-
`
`00+——-
`
`
`
`»
`
`————O—
`
`»+ ——0
`
`——0——0
`
`»+o——+
`
`-»+000—
`
`——+-+0
`
`00—»+0
`
`This is an3§gchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0360
`
`Aerohive - Exhibit 1025
`0360
`
`

`

`CSMA/CD
`
`Data
`
`octet
`80
`
`81
`
`82
`
`83
`
`84
`
`85
`
`86
`
`87
`
`Table 23A—1b—1OOBASE-T4 836T code table
`
`Data
`
`octet
`A0
`
`A1
`
`A2
`
`A3
`
`A4
`
`A5
`
`A6
`
`A7
`
`6T code group
`0—o++—
`
`00—+—-»
`
`0—0+—--
`
`—00+—-»
`
`—00+--—
`
`oo---»--
`
`0—0—
`
`—OO—---
`
`Data
`
`octet
`c0
`
`c1
`
`C2
`
`c3
`
`C4
`
`c5
`
`C6
`
`C7
`
`6T code group
`-»—--o+—
`
`
`
`-»+—+—o
`
`-——--+—0
`
`—+--+—o
`
`—+—-0+—
`
`»— —0+
`
`Data
`
`octet
`:30
`
`:31
`
`E2
`
`33
`
`:34
`
`35
`
`:6
`
`:37
`
`6T code group
`-»—+00—
`
`
`
`-»+—o—0
`
`-——+O—O
`
`—++0—0
`
`—++00—
`
`++--00
`
`+—+—oo
`
`—+——00
`
`IEEE
`Std 802.3u-1995
`
`6T code group
`+—o--+—
`
`
`
`0+—--—+
`
`+—0—-—+
`
`—0+--—+
`
`—0+—---—
`
`o+--»+
`
`+—o—
`
`—0-—-—
`
`—+0-
`
`
`
`
`
`
`
`—
`
`
`
`0—-———
`
`—+0———
`
`+O—-—+
`
`+0——-—
`
`o—+—»-
`
`—+O—-—
`
`»o——»+
`
`—000-
`
`
`
`-%
`
`I:
`
`
`
`~
`
`?0
`
`:8
`
`39
`
`EA
`
`
`
`
`
`
`
`—+—+-—
`
`——++—-
`
`—+—+——
`
`+——+—
`
`+——+-——
`
`——+—»
`
`—+——
`
`+———»»
`
`
`
`-»+--0-»
`
`—+——0—-
`
`
`
`o+00+—
`
`OO—-—0
`
`0+0—-—0
`»OO+—O
`
`-000+—
`
`
`oo+—0-»
`
`O+0—O—-
`
`»00—0-»
`
`——-O——
`
`CB
`
`C9
`
`CA
`
`CB
`
`CC
`
`CD
`
`
`C3
`
`CF
`
`88
`
`89
`
`8A
`
`8B
`
`8C
`
`83
`
`83
`8F
`
`o+ooo— A8
`
`
`
`OO—O—O
`
`-0000— AC
`
`0+00—O
`
`“000—0
`
`00+—00
`
`0+0—00
`
`-»00—00
`
`A9
`
`AA
`
`AB
`
`AD
`
`
`A3
`
`AF
`
`
`
`0—000-
`
`00—0»o
`
`O—OO»O
`
`—OOO--O
`
`—oooo+
`
`00—+oo
`
`O—0+OO
`
`—00+oo
`
`30
`
`31
`
`32
`
`D3
`
`34
`
`35
`
`36
`
`37
`
`B0
`
`B1
`
`B2
`
`B3
`
`B4
`
`B5
`
`B6
`
`B7
`
`
`
`
`
`»+——+o
`
`»—-—+0
`
`—
`
`—+0
`
`—+-o—+
`
`» —»0—
`
`-——-0—
`
`-»0—
`
`
`—
`
`Fl
`
`E2
`
`F3
`
`F4
`
`F5
`
`F6
`
`F7
`
`90
`
`91
`
`92
`
`93
`
`94
`
`95
`
`96
`
`97
`
`
`
`
`
`-—+——+
`
`»+——-—
`
`»—+—-—
`
`—++— —
`
`—++——+
`
`++—+——
`
`+—++——
`
`—+++——
`
`
`
`
`
`
`
`0+—0»0
`
`»—OO-»0
`
`—0+0--0
`
`—0+00+
`
`o+—-00
`
`+—O—-OO
`
`—o+-00
`
`
`
`
`
`38
`
`39
`
`3A
`
`3B
`
`3c
`
`DD
`
`
`33
`
`3F
`
`98
`
`99
`
`9A
`
`9B
`
`9c
`
`9D
`
`9E
`
`9F
`
`O+0——+
`
`00+—-—
`
`
`
`0+0———
`
`-00———
`
`»00——+
`00++——
`
`o+o+——
`
`+OO+——
`
`B8
`
`B9
`
`BA
`
`BB
`
`BC
`
`BD
`
`BE
`
`BF
`
`
`
`—-—00+
`
`——+o--o
`
`
`
`—-—O-O
`
`+——O-O
`
`+——oo+
`
`——++OO
`
`—+—+oo
`
`+——+OO
`
`
`
`
`
`
`
`O—-00—+
`
`00 —+0
`
`0—0—+0
`
`F8
`
`F9
`
`EA
`
`——-000+
`
`o—+0»0
`
`——-00—-0
`
`
`
`
`
`EB
`
`-00—+0
`
`»000—+
`00+-O— ED
`
`FC
`
`o+0+0— FE
`
`
`
`+00--O—
`
`FF
`
`-0—O-O
`
`»0—00+
`0—+—-OO
`
`—+o--00
`
`+0——-OO
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`O3 6 1
`
`Aerohive - Exhibit 1025
`0361
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 23B
`
`(informative)
`
`Noise budget
`
`SUPPLEMENT TO 802.3:
`
`Worst-case values for noise effects in the IOOBASE-T4 system are as shown in tables 23B-1 and 23B-2.
`
`Table 23B-1—Carrier presence analysis
`
`Table 23B-2—Far-end signal analysis
`
`
`
`This is an34>gchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0362
`
`

`

`CSMA/CD
`
`Annex 23C
`
`(informative)
`
`IEEE
`Std 802.3u-1995
`
`Use of cabling systems with a nominal differential characteristic
`impedance of 120 Q
`
`The lOOBASE-T4 standard specifies only the use of 100 9. link segments for conformance. Since
`ISO/IEC 11801: 1995 also recognizes 120 Q cabling, this informative annex specifies the conditions for
`using cabling systems with a nominal characteristic impedance of 120 Q by lOOBASE-T4 conformant
`stations.
`
`The use of cables with a characteristic impedance outside the range specified in 23.6 will generally
`increase the mismatching effects in the link components, inducing additional noise in the received signals.
`
`In particular, the use of a homogeneous link segment having a characteristic impedance of 120 Q :l:15 9
`over the frequency band 1 to 16 MHz may add up to 1.4% of additional noise to the signals at the input of
`the receivers (worst-case short-length link segment).
`
`Therefore, in order to keep the overall noise (MDFEXT + reflections) at the same value as for a 100 9
`link segment when using a 120 9 link segment, the minimum ELFEXT loss requirement for the cable
`must be increased by 2 dB (i.e., from 23 dB to 25 dB at 12.5 MHz, see 23.6.3.2). Accordingly, the
`MDFEXT noise requirement shall be decreased from 87 mV peak to 69 mV peak. In practice, this means
`that cables rated category 4 or higher, as specified in ISO/[EC 11801: 1995, are required when 120 9
`cables are used with lOOBASE-T4 compliant PMDs.
`
`NOTES
`
`l—The use of 100 Q cords at end points in conjunction with 120 Q premises cabling may be tolerated provided that all
`the components of the link are of category 5, as defined in ISO/IEC 11801: 1995.
`
`2—The use of 100 Q cords at any intermediate cross-connect points on 120 9 links as well as the use of 120 Q cords in
`conjunction with 100 Q premises cabling is not allowed since it would result in worst-case jitter greater than that
`allowed in this standard.
`
`CAUTION—Users of this annex are further advised to check with the manufacturer of the particular lOOBASE—T4 cou-
`plers they intend to use with a 120 9 link to see whether those couplers can operate correctly on cables with Zc as high
`
`as 120 Q: 15 Q.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0363
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 27A
`
`(normative)
`
`SUPPLEMENT TO 802.3:
`
`Repeater delay consistency requirements
`
`Proper operation of the network requires that repeaters do not cause the Inter-Packet Gap (IPG) to
`disappear by propagating the end of any carrier event to different output ports with greatly different delay
`times. Maximum port-to-port delays have been assigned as absolute delays to meet requirements for
`detection of collision within a slot time and limiting the length of collision fragments to less than
`minimum frame size. To avoid specification of minimum input—to-output propagation time as absolute
`values that reduce implementation flexibility, these delays are instead implied by imposing a triangular
`delay inequality relationship.
`
`Consider three ports {A, B, C}. Using the notation SOP(xy) to mean the start-of—packet delay for an input
`at port x to resulting output on port y, repeaters shall achieve this relationship for all groups of three ports
`within a repeater set:
`
`SOP(AC) < SOP(AB) + SOP(BC)
`
`Following a frame transmitted by node A that propagates to nodes B and C, this constraint ensures that
`node B cannot complete an IPG timer and initiate a transmission that arrives at node C before node C has
`also advanced its own IPG timer sufliciently that a pending frame can contend for access to the network.
`
`There is a second delay consistency requirement, one that relates to jam propagation by repeaters. Using a
`notation similar to that above, SOJ(xy) stands for the start-of—jam propagation delay from port x to port y
`and EOJ(xy) for the end—of—jam delay between same two ports.
`
`To ensure proper detection of collisions and avoid generation of fragments that exceed minimum frame
`size, maximum values have been imposed on SOJ and EOJ delays through repeaters. No specific minima
`have been specified as all delays less than the maxima meet the collision detection and fragment length
`criteria. To prevent the jam pattern fi'om shrinking excessively as it propagates through repeaters,
`repeaters shall meet this relationship between all pairs of ports:
`
`EOJ(AB) >= SOJ(AB) — 4 bit times
`
`This is angegrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0364
`
`

`

`CSMA/CD
`
`Annex 28A
`
`(normative)
`
`IEEE
`Std 802.3u-1995
`
`Selector Field definitions
`
`The Selector Field, S[4:0] in the Link Code Word, shall be used to identify the type of message being sent
`by Auto-Negotiation. The following table identifies the types of messages that may be sent. As new
`messages are developed, this table will be updated accordingly.
`
`The Selector Field uses a 5-bit binary encoding, which allows 32 messages to be defined. All unspecified
`combinations are reserved. Reserved combinations shall not be transmitted.
`
`Table 28A-1—Selector Field value mappings
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0365
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 283
`
`(normative)
`
`SUPPLEMENT TO 802.3:
`
`IEEE 802.3 Selector Base Page definition
`
`This annex provides the Technology Ability Field bit assignments, Priority Resolution table, and Message
`Page transmission conventions relative to the IEEE 802.3 Selector Field value within the base page
`encoding.
`
`As new IEEE 802.3 LAN technologies are developed, a reserved bit in the Technology Ability Field may
`be assigned to each technology by the standards body.
`
`The new technology will then be inserted into the Priority Resolution hierarchy and made a part of the
`Auto-Negotiation standard. The relative hierarchy of the existing technologies will not change, thus
`providing backward compatibility with existing Auto-Negotiation implementations.
`
`It is important to note that the reserved bits are required to be transmitted as logic zeros. This guarantees
`that devices implemented using the current priority table will be forward compatible with fiiture devices
`using an updated priority table.
`
`283.1 Selector field value
`
`The value of the IEEE 802.3 Selector Field is S[4:0] = 00001.
`
`2832 Technology Ability Field bit assignments
`
`The Technology bit field consists of bits D5 through D12 (A0—A8 respectively) in the IEEE 802.3
`Selector Base Page. Table 28B-1 summarizes the bit assignments.
`
`Note that the order of the bits within the Technology Ability Field has no relationship to the relative
`priority of the technologies.
`
`Table 28B-1—Technology Ability Field bit assignments
`
`
`
`This is angArchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0366
`
`

`

`CSMA/CD
`
`285.3 Priority resolution
`
`IEEE
`Std 802.3u-1995
`
`Since two devices may have multiple abilities in common, a prioritization scheme exists to ensure that the
`highest common denominator ability is chosen. The following list shall represent the relative priorities of
`the technologies supported by the IEEE 802.3 Selector Field value, where priorities are listed from
`highest to lowest.
`
`a)
`b)
`c)
`d)
`e)
`
`100BASE—TX fiill duplex
`lOOBASE—T4
`100BASE—TX
`10BASE—T full duplex
`10BASE-T
`
`The rational for this hierarchy is straightforward. 10BASE—T is the lowest common denominator and
`therefore has the lowest priority. Full-duplex solutions are always higher in priority than their half—duplex
`counterparts. 100BASE-T4 is ahead of lOOBASE—TX because 100BASE—T4 runs across a broader
`spectrum of copper cabling. The relative order of the technologies specified herein shall not be changed.
`As each new technology is added, it shall be inserted into its appropriate place in the list, shifting
`technologies of lesser priority lower in priority. If a vendor-specific technology is implemented, the
`priority of all IEEE 802.3 standard technologies shall be maintained, with the vendor-specific technology
`inserted at any appropriate priority location.
`
`283.4 Message Page transmission convention
`
`Each series of Unformatted Pages shall be preceded by a Message Page containing a Message Code that
`defines how the following Unformatted Pages will be used.
`
`Next Page message codes should be allocated globally across Selector Field values so that meaningful
`communication is possible between technologies using different Selector Field values.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0367
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 28C
`
`(normative)
`
`SUPPLEMENT TO 802.3:
`
`Next Page Message Code Field definitions
`
`The Message Code Field of a message page used in Next Page exchange shall be used to identify the
`meaning of a message. The following table identifies the types of messages that may be sent. As new
`messages are developed, this table will be updated accordingly.
`
`The Message Code Field uses an 11-bit binary encoding that allows 2048 messages to be defined. A11
`Message Codes not specified shall be reserved for IEEE use or allocation.
`
`Table 286-1—Message Code Field values
`
`
`
`286.1 Message code #O—Auto-Negotiation reserved code 1
`
`This code is reserved for fitture Auto-Negotiation function enhancements. Devices shall not transmit this
`code.
`
`286.2 Message code #1—Null Message code
`
`The Null Message code shall be transmitted during Next Page exchange when the Local Device has no
`further messages to transmit and the Link Partner is still transmitting valid Next Pages. See 28.2.3.4 for more
`details.
`
`This is angles—chive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0368
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`286.3 Message code #2—Technology Ability extension code 1
`
`This Message Code is reserved for future expansion of the Technology Ability Field and indicates that a
`defined user code with a specific Technology Ability Field encoding follows.
`
`28C.4 Message code #3—Technology Ability extension code 2
`
`This Message Code is reserved for future expansion of the Technology Ability Field and indicates that
`two defined user codes with specific Technology Ability Field encodings follow.
`
`28C.5 Message code #4—Remote fault number code
`
`This Message Code shall be followed by a single user code whose encoding specifies the type of fault that
`has occurred. The following user codes are defined:
`
`0: RF Test
`
`This code can be used to test Remote Fault operation.
`1: Link Loss
`2: Jabber
`3: Parallel Detection Fault
`
`This code may be sent to identify when bit 6.4 is set.
`
`28C.6 Message code #5—0rganizationally Unique Identifier (OUI) tag code
`
`The OUI Tagged Message shall consist of a single message code of 0000 0000 0101 followed by four user
`codes defined as follows. The first user code shall contain the most significant 11 bits of the OUI (bits
`23:13) with the most significant bit in bit 10 of the user code. The second user code shall contain the next
`most significant 11 bits of the OUI (bits 12:2) with the most significant bit in bit 10 of the user code. The
`third user code shall contain the remaining least significant 2 bits of the OUI (bits 1:0) with the most
`significant bit in hit 10 of the user code. Bits 8:0 of the fourth user contain a user—defined user code value
`that is specific to the OUI transmitted. The fourth and final user code shall contain a user-defined user
`code value that is specific to the OUI transmitted.
`
`28C.7 Message code #6—PHY identifier tag code
`
`The PHY ID tag code message shall consist of a single message code of 0000 0000 0110 followed by four
`user codes defined as follows. The first user code shall contain the most significant 11 bits of the PHY ID
`(2.15:5) with the most significant bit in hit 10 of the user code. The second user code shall contain bits
`2.4:0 to 3.15210 of the PHY ID with the most significant bit in bit 10 of the user code. The third user code
`shall contain bits 3.9:0 of the PHY ID with the most significant bit in bit 10 of the user code. Bit 0 in the
`third user code shall contain a user-defined user code value that is specific to the PHY ID transmitted. The
`fourth and final user code shall contain a user-defined user code value that is specific to the PHY ID
`transmitted.
`
`286.8 Message code #2047—Auto-Negotiation reserved code 2
`
`This code is reserved for future Auto-Negotiation function enhancements. Devices shall not transmit this
`code.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stangfird.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0369
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 29A
`
`(informative)
`
`SUPPLEMENT TO 802.3:
`
`DTE and repeater delay components
`
`29A.1 DTE delay
`
`Round-trip DTE delay = MAC transmit start to MDI output
`+ MDI input to MDI output (worst case, nondeferred)
`+ MDI input to collision detect
`
`NOTES
`
`l—Refer to clauses 23, 24, 25, and 26.
`
`2—Worst-case values are used for the one T4 and one TX/FX value shown in table 29-3. (TX/FX values for MAC trans-
`mit start and MDI input to collision detect; T4 value for MDI input to MDI output.)
`
`29A.2 Repeater delay
`
`Repeater delay: SOP (start-of—packet propagation delay)
`+ SOJ (start—of—jam propagation delay)
`
`NOTE—Refer to clause 27.
`
`This is angles—chive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0370
`
`

`

`CSMA/CD
`
`Annex 293
`
`(informative)
`
`IEEE
`Std 802.3u-1995
`
`Recommended topology documentation
`
`It is strongly recommended that detailed records documenting the topology components of lOOBASE-T
`networks be prepared and maintained to facilitate subsequent modification. Proper lOOBASE—T topology
`design requires an accurate knowledge of link segment and hub parameters to ensure proper operation of
`single and multi-segment, single collision domain networks. Link segment documentation is site-specific
`and requires careful documentation. It is recommended that the information shown in table 29B-1 be
`collected for each link segment and archived for future reference. Hub performance parameters may be
`obtained from manufacturer documentation.
`
`Table 293-1—Recommended link segment documentation
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0371
`
`

`

`IEEE
`Std 802.3u-1995
`
`Annex 30A
`
`(normative)
`
`SUPPLEMENT TO 802.3:
`
`GDMO specification for 802.3 managed object classes
`
`This annex formally defines the protocol encodings for CMIP and ISO/IEC 15802-2: 1995 [IEEE 802.1B]
`for the IEEE 802.3 Managed Objects using the templates specified in ISO/IEC 10165-4: 1992, Guidelines
`for the definition of managed objects (GDMO). The application of a GDMO template compiler against
`30A.1 to 30A.8 will produce the proper protocol encodings.
`
`NOTE—The arcs (that is, object identifier values) defined in annex 30A deprecate the arcs previously defined in Annexes D1
`(Layer Management), D2 (Repeater Management), and D3 (MAU Management). See IEEE Std 802.1F-1993, annex C.4.
`
`Each attribute definition in this clause references directly by means of the WITH ATTRIBUTE SYNTAX
`construct or indirectly by means of the DERIVED FROM construct an ASN.1 type or subtype that defines
`the attribute’s type and range. Those ASN.1 types and subtypes defined exclusively for CSMA/CD
`Management appear in a single ASN.1 module at the end of this annex.
`
`Counters for these protocol encodings are specified as either 32 or 64 bits wide. Thirty-two bit counters
`are used for the protocol encoding of counter attributes, providing the minimum rollover time is 58 min or
`more. Sixty-four bit counters are used for the protocol encoding of counter attributes that could roll over
`in less than 58 min with a 32—bit counter. Approximate counter rollover times are provided as notes below
`each counter BEHAVIOUR definition. Approximate rollover time for 100 Mb/s operation is one tenth the
`value of the approximate rollover time for 10 Mb/s operation except where indicated, or where one tenth
`the value for 10 Mb/s operation is less than 58 min. For formal definition of the counter, refer to the
`BEHAVIOUR bCMCounter in 30B.1.
`
`30A.1 DTE MAC entity managed object class
`
`30A.1.1 DTE MAC entity formal definition
`
`oMACEntity
`
`MANAGED OBJECT CLASS
`
`DERIVED FROM
`
`CHARACTERIZED BY
`
`pBasic
`
`ATTRIBUTES
`ACTIONS
`
`CONDITIONAL PACKAGES
`
`pMandatory
`ATTRIBUTES
`
`REGISTERED AS
`
`“CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 :
`1992”:top;
`
`PACKAGE
`aMACID
`acInitializeMAC;
`
`GET;
`
`PACKAGE
`GET,
`aFramesTransmittedOK
`GET,
`aSingleCollisionFrames
`GET,
`aMultipleCollisionFrames
`GET,
`aFramesReceivedOK
`GET,
`aFrameCheckSequenceErrors
`GET;
`aAlignmentErrors
`{iso(1) member-body(2) us(840) 802dot3(10006)
`
`This is anggg‘chive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0372
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`PRESENT IF
`
`pRecommended
`ATTRIBU 1 ES
`
`ACTIONS
`
`REGISTERED AS
`
`PRESENT IF
`
`pOptional
`ATTRIBUTES
`
`ACTIONS
`REGISTERED AS
`
`PRESENT IF
`
`ATTRIBUTES
`REGISTERED AS
`
`PRESENT IF
`
`pArray
`
`pExcessiveDeferral
`ATTRIBUTES
`REGISTERED AS
`
`csmacdmgt(30) package(4) macMandatoryPkg(1)};
`Conformance to DTE Management is desired;
`PACKAGE
`
`GET,
`aOctetsTransmittedOK
`aFramesWithDeferredJGm'ssions GET,
`aLateCollisions
`GET,
`aFramesAbortedDueToXSColls GET,
`aFramesLostDueToIntMACXmitError GET,
`aCarrierSenseErrors
`GET,
`aOctetsReceivedOK
`GET,
`aFramesLostDueToIntMACRchn'or
`GET,
`aPromiscuousStatus
`GET-SET,
`aReadMulticastAddressList
`GET;
`acAddGroupAddress,
`acDeleteGroupAddress;
`{iso(1) member-body(2) us(840) 802dot3(10006)
`csmacdmgt(30) package(4)
`macRecomInendedeg(2)} ;
`The Recommended Package is implemented;
`PACKAGE
`
`GET,
`aMulticastFramesXmittedOK
`GET,
`aBroadcastFramesXmittedOK
`GET,
`aMulticastFramesReceivedOK
`aBroadcastFramesReceivedOK GET,
`aInRangeLengthErrors
`GET,
`aOutOfRangeLengthField
`GET,
`aFrameTooLongErrors
`GET,
`aMACEnableStatus
`GET-SET,
`aTransmitEnableStatus
`GET—SET,
`aMulticastReceiveStatus
`GET-SET,
`aReadWriteMACAddress
`GET-SET;
`acExecuteSelfTest;
`{iso(1) member-body(2) us(840) 802dot3(10006)
`csmacdmgt(30) package(4) optionalPkg(3)};
`The Optional Package and the Recommended Package
`are implemented;
`PACKAGE
`
`GET;
`aCollisionFrames
`{iso(1) member-body(2) us(840) 802dot3(10006)
`csmacdmgt(30) package(4) arrayPkg(4)};
`The Array Package and the Recommended Package
`are implemented;
`PACKAGE
`
`PRESENT IF
`
`REGISTERED AS
`
`aFramesWithExcessiveDeferral GET;
`{iso(1) member-body(2) us(840) 802dot3(10006)
`csmacdmgt(30) package(4)
`excessiveDeferralPkg(5)} ;
`The ExcessiveDeferral Package and the
`Recommended Package are implemented;
`{iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)
`managedObj ectClass(3) macObj ectClass(l)};
`
`nbMACName
`
`NAME BINDING
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
` bit 1025
`0373
`
`Aerohive - Exhibit 1025
`0373
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`SUBORDINATE OBJECT CLASS
`NAMED BY SUPERIOR OBJECT CLASS
`
`oMACEntity;
`
`WITH ATTRIBUTE
`REGISTERED AS
`
`“ISO/IEC 10165-2”:system;
`aMACID;
`{iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)
`nameBinding(6) macName(1)};
`
`nbMACMom'tor
`
`NAME BINDING
`
`SUBORDINATE OBJECT CLASS
`NAMED BY SUPERIOR OBJECT CLASS
`
`“IEEE802.1F”:ewm