CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`Table 25-2—UTP MDI contact assignments
`
`
`
`25.4.6 Replacement of 11.2, “Crossover function”
`
`Clause 11.2 of TP-PMD is replaced with the following:
`
`A crossover function compliant with 14.5.2 shall be implemented except that a) the signal names are those
`used in TP-PMD, and b) the contact assignments for STP are those shown in table 8-2 of TP-PMD. Note
`that compliance with 14.5 .2 implies a recommendation that crossover (for both UTP and STP) be per-
`formed within repeater PHYS.
`
`25.4.7 Change to A.2, “DDJ test pattern for baseline wander measurements”
`
`The length of the test pattern specified in TP-PMD annex A.2 may be shortened to accommodate feasible
`l00BASE-X measurements, but shall not be shorter than 3000 code-groups.
`
`NOTE—This pattern is to be applied to the M11. (When applied to the MAC, the nibbles within each byte are to be
`swapped. E.g., as delivered to the MAC, the test pattern would start, "60 c9 16 ...".)
`
`25.4.8 Change to annex G, “Stream cipher scrambling function”
`
`An example of a stream cipher scrambling implementation is shown in TP-PMD annex G. This may be
`modified to allow synchronization solely on the IDLE sequences between packets.
`
`25.4.9 Change to annex I, “Common mode cable termination"
`
`The contact assignments shown in TP-PMD figures I-1 and 1-2 shall instead comply with those specified
`in table 25-2.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgrd.
`
`0214
`
`it 1025
`
`Aerohive - Exhibit 1025
`
`0214
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`25.5 Protocol Implementation Conformance Statement (PICS) profonna for clause 25,
`Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE-TX24
`
`25.5.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to IEEE Std 802.3u-1995, Physical
`Medium Dependent (PMD) sublayer and baseband medium, type 100BASE—TX, shall complete the fol-
`lowing Protocol Implementation Conformance Statement (PICS) proforma.
`
`A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
`PICS proforma, can be found in clause 21.
`
`25.5.2 Identification
`
`25.5.2.1 Implementation identification
`
`Supplier
`
`Contact point for enquiries about the PICS
`
`Implementation Name(s) and Version(s)
`
`Other information necessary for full identification—e.g.,
`name(s) and Version(s) for machines and/or operating
`systems; System Names(s)
`
`NOTES
`
`(e.g., Type, Series, Model).
`
`1—Only the first three items are required for all implementations; other information may be completed as appropri-
`ate in meeting the requirements for the identification.
`2—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s terminology
`
`25.5.2.2 Protocol summary
`
`Identification of protocol standard
`
`IEEE Std 802.3u-1995, Physical Medium Dependent
`(PMD) sublayer and baseband medium, type
`IOOBASE-TX
`
`Date of Statement
`
`Identification ofamendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`Yes [ ]
`No [ ]
`Have any Exception items been required?
`(See clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3u-1995.)
`
`24Copyright releasefor PICSpmformas Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`This is anlegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`02 l 5
`
`Aerohive - Exhibit 1025
`
`0215
`
`

`

`CSMNCD
`
`25.5.3 Major capabilitiesloptions
`
`IEEE
`Std 802.3u-1995
`
`25.2
`
`Supports unshielded twisted
`pair
`
`25.2
`
`Supports shielded twisted pair
`
`0/ 1
`
`25.5.4 PICS proforma tables for the Physical Medium Dependent (PMD) sublayer and base-
`band medium, type 100BASE-TX
`
`25.5.4.1 General compatibility considerations
`
`% G
`
`N1
`
`Integrates 100BASE-X PMA
`and PCS
`
`
`
`25.1
`
`M
`
`See clause 24
`
`25.5.4.2 PMD compliance
`
`Subclause
`
`Value/Comment
`
`length
`
`Compliance with 100BASE-X
`PMD Service Interface
`
`Compliance with ANSI
`X3237: l99X, 7, 8 (excluding
`8.3), 9, 10, 11 and normative
`annex A, with listed exceptions
`
`Precedence over ANSI
`X3 .23 7-1 99X
`
`MDI contact assignments for
`unshielded twisted pair
`
`Compliance with crossover
`function of 14.5.2 with listed
`adaptations
`
`Minimum jitter test pattern
`
`3000 code-groups
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`O2 16
`
`Aerohive - Exhibit 1025
`
`0216
`
`

`

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

`

`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`26. Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE—FX
`
`26.1 Overview
`
`This clause specifies the 10OBASE-X PMD (including MDI) and fiber optic medium for multi-mode fiber,
`100BASE—FX. In order to form a complete IOOBASE-FX Physical Layer it shall be integrated with the
`10OBASE-X PCS and PMA of clause 24, which are assumed incorporated by reference. As such, the
`100BASE—FX PMD shall comply with the PMD service interface specified in 24.4.1.
`
`26.2 Functional specifications
`
`The 100BASE—FX PMD (and MDI) is specified by incorporating the FDDI PMD standard, ISO 9314-3:
`1990, by reference, with the modifications noted below. This standard provides support for two optical
`fibers. For improved legibility in this clause, ISO 9314-3: 1990 will henceforth be referred to as
`fiber—PMD.
`
`26.3 General exceptions
`
`The IOOBASE-FX PMD is precisely the PMD specified as fiber-PMD, with the following general modifi-
`cations:
`
`a)
`
`b)
`
`c)
`
`(1)
`
`The Scope and General description discussed in fiber-PMD 1 and 5 relate to the use of those stan-
`dards with an FDDI PHY, ISO 9314-1: 1989, and MAC, ISO 9314-2: 1989. These clauses are not
`relevant to the use of the PMD with 10OBASE-X.
`
`The Normative references, Definitions and Conventions of fiber-PMD 2, 3, and 4 are used only as
`necessary to interpret the applicable sections of fiber-PMD referenced in this clause.
`The PMD Service Specifications of fiber-PMD 6 are replaced by those specified in 24.4.1. The
`IOOBASE-FX PMD Service specification is a proper subset of the PMD service specification in
`fiber-PMD.
`
`There are minor terminology differences between this standard and fiber-PMD that do not cause
`ambiguity. The terminology used in 10OBASE-X was chosen to be consistent with other IEEE 802
`standards, rather than with FDDI. Terminology is both defined and consistent within each standard.
`Special note should be made of the interpretations shown in table 26-1.
`
`Table 26-1—lnterpretation of general FDDI terms and concepts
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanqigajd.
`
`
`
`Aerohive - Exhibit 1025
`
`0218
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Table 26-1—lnterpretation of general FDDI terms and concepts (Continued)
`
`FDDI term or concept
`
`Interpretation for 100BASE-X
`
`PHY (or PHY-2)
`
`PHY Service Data Unit (SDU)
`
`PMA; i.e., PMD client
`
`stream
`
`PM_SIGNAL.indication (Signal_Detect)
`
`PMD_SIGNAL.indicate (signal_status)
`
`PM_UNITDATA.indication (PM_Indication)
`
`PMD_UNITDATA.indicate (nrzi-bit)
`
`PM_UNITDATA request (PM_Request)
`
`PMD_UNITDATA request (nrzi-bit)
`
`preamble
`
`Quiet Line State (QLS)
`
`inter-packet IDLEs
`
`<unused>
`
`SM_PM_BYPASS request (Control_Action)
`
`SM_PM_CONTROL request (Control_Action)
`
`Assume:
`SM_PM_BYPASS request (Control_Action = Insert)
`Assume:
`SM_PM_CONTROL request (Control_Action =
`Transmit_Enable)
`
`SM_PM_SIGNAL.indication (Signal_Detect)
`
`<unused>
`
`Station Management (SMT)
`
`<no comparable entity>
`
`symbol
`
`code-group
`
`26.4 Specific requirements and exceptions
`
`The IOOBASE-FX PMD (including MDD and baseband medium shall conform to the requirements of
`fiber-PMD 8, 9, and 10. In fiber-PMD, informative annexes A through G provide additional information
`useful to PMD sublayer implementors. Where there is conflict between specifications in fiber-PMD and
`those in this standard, those of this standard shall prevail.
`
`26.4.1 Medium Dependent Interface (MDI)
`
`The l00BASE—FX medium dependent interface (MDI) shall conform to one of the following connectors.
`The recommended alternative is the Low Cost Fibre Optical Interface Connector.
`
`a)
`
`Low Cost Fibre Optical Interface Connector (commonly called the duplex SC connector) as speci-
`fied in ANSI X3.237-199X, 7.1.1 through 7.3.1, inclusive.
`
`b) Media Interface Connector (MIC) as specified in fiber-PMD 7 and annex F. When the MIC is used,
`the receptacle shall be keyed as “M”.
`
`c)
`
`Optical Medium Connector Plug and Socket (commonly called ST connector) as specified in 15.3.2.
`
`26.4.2 Crossover function
`
`A crossover function shall be implemented in every cable-pair link. The crossover function connects the
`transmitter of one PHY to the receiver of the PHY at
`the other end of the cable-pair link. For
`l00BASE-FX, the crossover function is realized in the cable plant.
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0219
`
`Aerohive - Exhibit 1025
`
`0219
`
`

`

`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`26.5 Protocol Implementation Conformance Statement (PICS) proforma for clause 26,
`Physical Medium Dependent (PMD) sublayer and baseband medium, type
`100BASE-FX25
`
`26.5.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to IEEE Std 802.3u-1995, Physical
`Medium Dependent (PMD) sublayer and baseband medium, type 100BASE—FX, shall complete the fol-
`lowing Protocol Implementation Conformance Statement (PICS) proforma.
`
`A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
`PICS proforma, can be found in clause 21.
`
`26.5.2 Identification
`
`26.5.2.1 Implementation identification
`
`Supplier
`
`Contact point for enquiries about the PICS
`
`Implementation Name(s) and Version(s)
`
`Other information necessary for full identification—e.g.,
`name(s) and version(s) for machines and/or operating
`systems; System Names(s)
`
`NOTES
`
`(e.g., Type, Series, Model).
`
`l—Only the first three items are required for all implementations; other information may be completed as appropri-
`ate in meeting the requirements for the identification.
`2—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s terminology
`
`26.5.3 Protocol summary
`
`Identification of protocol standard
`
`IEEE Std 802.3u-1995, Physical Medium Dependent
`(PMD) sublayer and baseband medium, type l00BASE-FX
`
`Identification of amendments and corrigenda to this PICS
`proforma that have been completed as part of this PICS
`
`Have any Exception items been required?
`
`No [ ]
`
`Yes [ ]
`
`(See clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3u-1995.) Date of Statement
`
`25Copyright releasefor PICSpmformas Users of this standard may freely reproduce the PICS proforma in this annex so that it can be
`used for its intended purpose and may further publish the completed PICS.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0220
`
`Aerohive - Exhibit 1025
`
`0220
`
`

`

`IEEE
`Std 802.3u-1995
`
`26.5.4 Major capabilitiesloptions
`
`SUPPLEMENT TO 802.3:
`
`See 15.3.2
`
`Subclause
`
`Value/Comment
`
`Recommended.
`See ANSI X3.237-199X, 7.1.1
`through 7.3.1
`
`See ISO 9314-3: 1990, 7 and
`annex F
`
`Supports Low Cost Fibre
`Optical Interface Connector
`(duplex SC)
`
`Supports Media Interface Con-
`nector (MIC)
`
`Supports Optical Medium
`Connector Plug and Socket
`(ST)
`
`26.5.5 PICS proforma tables for Physical Medium Dependent (PMD) sublayer and baseband
`medium, type 100BASE-FX
`
`26.5.5.1 General compatibility considerations
`
`and PCS
`
`M
`
`See clause 24
`
`GN1
`
`Integrates 100BASE-X PMA
`
`26.1
`
`26.5.5.2 PMD compliance
`
`Subclause
`
`Status
`
`Value/Comment
`
`See 24.2.3
`
`Crossover function in cable
`
`Compliance with 100BASE-X
`PMD Service Interface
`
`Compliance with ISO 9314-3:
`1990 8, 9, and 10
`
`Precedence over ISO 9314-3:
`1990
`
`MIC receptacle keying
`
`This is anzagrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0221
`
`Aerohive - Exhibit 1025
`
`0221
`
`

`

`CSMNCD
`
`IEEE
`Std B{}2.3u-1995
`
`27. Repeater for 100 Mbls baseband networks
`
`27.1 Overview
`
`27.1.1 Scope
`
`Clause 27 defines the functional and electrical characteristics of a repeater for use with IOOBASE-T 100 Mb/s
`baseband networks. A repeater for any other ISOXIEC 8802-3 network type is beyond the scope of this clause.
`The relationship of this standard to the entire ISO/[EC S802-3 CSMA/CD LAN standard is shown in figure 27-1.
`The purpose of the repeater is to provide a simple, inexpensive, and flexible means of coupling two or more
`segments.
`
`OSI
`REFERENCE
`MODEL
`LAYERS
`
`APPLICATION
`
`PRESENTATION
`
`SESSION
`
`TRANSPORT
`
`NETWORK
`DATA LINK
`
`PHYSICAL
`
`LAN
`CSMNCQ
`LAYERS
`
`1DDBASE—T
`Baseband
`Repeater
`Unit
`
`PMA
`" PMD
`"AUTONEG
`MDI—h
`MEDIUM é
`1{]=|J Mhfs link segment
`
`PHY
`
`PMA
`" PMD
`"AUTONEG
`MDl——)-
`MEDIUM
`100 Mbls link segment
`
`1D{lBASE—T
`Baseband
`Repeater Set
`
`MDI : MEDIUM DEPENDENT INTERFACE
`MII = MEDIA INDEPENDENT INTERFACE
`
`PCS = PHYSICAL CODING SUBLAYER
`PMA : PHYSICAL MEDIUM ATTACHMENT
`PHY = PHYSICAL LAYER DEVICE
`PMD = PHYSICAL MEDIUM DEPENDENT
`
`" PMD is specified for 1fl0BASE—TX and —FX only; 10[]BASE—T4 does not use this layer.
`Use of MII between PCS and baseband repeater unit is optional.
`"" AUTONEG is optional.
`
`Figure 2?-1—1lJOBASE-T repeater set relationship to the OSI reference model
`
`27.1.1.1 Repeater set
`
`Repeater sets are an integral part of all 100 Mbfs baseband networks with more than two DTEs and are used
`to extend the physical system topology by providing a means of coupling two or n1ore segments. Multiple
`repeater sets are permitted within a single collision domain to provide the maximum connection path length.
`Segments may be connected directly by a repeater or a pair of repeaters that are, i.n turn, connected by a
`inter-repeater link (IRL). Allowable topologies shall contain only one operative signal path between any two
`points on the network. A repeater set is not a station and does not count toward the overall limit of 1024 sta-
`tions on a network.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanglard.
`
`Aerohive - EXhib'
`
`Aerohive - Exhibit 1025
`
`0222
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`A repeater set can receive, and if necessary decode, data from any segment under worst—case noise, timing,
`and signal amplitude conditions. It retransmits the data to all other segments attached to it with timing,
`amplitude, and, if necessary, coding restored. The retransmission of data occurs simultaneously with recep-
`tion. If a collision occurs, the repeater set propagates the collision event throughout the network by transmit-
`ting a Jam signal. A repeater set also provides a degree of protection to a network by isolating a faulty
`segment’s carrier activity from propagating through the network.
`
`27.1.1.2 Repeater unit
`
`A repeater unit is a subset of a repeater set containing all the repeater—specific components and functions,
`exclusive of PHY components and fimctions. A repeater unit connects to the PMA and, if necessary, the PCS
`sublayers of its PHYS.
`
`27.1.1.3 Repeater classes
`
`Two classes of repeater sets are defir1ed—Class I and Class II.
`
`Class I:
`
`Class II:
`
`A type of repeater set specified such that in a maximum length segment topology, only one such
`repeater set may exist between any two DTEs within a single collision domain.
`
`A type of repeater set specified such that in a maximum length segment topology, only two such
`repeater sets may exist between any two DTEs within a single collision domain.
`
`More complex topologies are possible in systems that do not use worst—case cable. See clause 29 for require-
`ments.
`
`27.1.2 Application perspective
`
`This subclause states the broad objectives and assumptions underlying the specification defined through
`clause 27.
`
`27.1.2.1 Objectives
`
`a)
`b)
`c)
`
`Provide physical means for coupling two or more LAN segments at the Physical Layer.
`Support interoperability of independently developed physical, electrical, and optical interfaces.
`Provide a communication charmel with a mean bit error rate, at the physical service interface equiv-
`alent to that for the attached PHY.
`
`Provide for ease of installation and service.
`(1)
`Ensure that fairness of DTE access is not compromised.
`e)
`Provide for 1ow—cost networks, as related to both equipment and cabling.
`f)
`g) Make use of building wiring appropriate for the supported PHYS and telephony wiring practices.
`
`27.1.2.2 Compatibility considerations
`
`All implementations of the repeater set shall be compatible at the MDI. The repeater set is defined to provide
`compatibility among devices designed by different manufacturers. Designers are free to implement circuitry
`within the repeater set in an application-dependent manner provided the appropriate PHY specifications are
`met.
`
`This is anzarchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0223
`
`1025
`
`Aerohive - Exhibit 1025
`
`0223
`
`

`

`CSMNCD
`
`27.1.2.2.1 Internal segment compatibility
`
`IEEE
`Std 802.3u-1995
`
`Implementations of the repeater set that contain a MAC layer for network management or other purposes,
`irrespective of whether they are connected through an exposed repeater port or are internally ported, shall
`conform to the requirements of clause 30 on that port if repeater management is implemented.
`
`27.1.3 Relationship to PHY
`
`A close relationship exists between clause 27 and the PHY clauses, clause 23 for the 100BASE-T4 PHY and
`clauses 24 to 26 for the IOOBASE-X PHYs. The PHY’s PMA, PCS, and MDI specification provide the
`actual medium attachment, including drivers, receivers, and Medium Interface Connectors for the various
`supported media. The repeater clause does not define a new PHY; it utilizes the existing PHYS complete and
`without modification.
`
`27.2 PMA interface messages
`
`The messages between the repeater unit and the PMA in the PHY utilizes the PMA service interface defined
`in 23.3 and 24.3. The PMA service interface primitives are summarized below:
`
`PMA_TYPE.indicate
`
`PMA_UNITDATA.request
`
`PMA_UNITDATA.indicate
`
`PMA_CARRIER.indicate
`
`PMA_LINK.indicate
`
`PMA_RXERROR.indicate
`
`27.3 Repeater functional specifications
`
`A repeater set provides the means whereby data from any segment can be received under worst case noise,
`timing, and amplitude conditions and then retransmitted with timing and amplitude restored to all other
`attached segments. Retransmission of data occurs simultaneously with reception. If a collision occurs, the
`repeater set propagates the collision event throughout the network by transmitting a Jam signal. If an error is
`received by the repeater set, no attempt is made to correct it and it is propagated throughout the network by
`transmitting an invalid signal.
`
`The repeater set provides the following functional capability to handle data flow between ports:
`
`a)
`
`b)
`
`Signal restoration. Provides the ability to restore the timing and amplitude of the received signal
`prior to retransmission.
`Transmitfimction. Provides the ability to output signals on the appropriate port and encoded appro-
`priately for that port. Details of signal processing are described in the specifications for the PHYS.
`Receivefimcrion. Provides the ability to receive input signals presented to the ports. Details of signal
`processing are described in the specifications for the PHYS.
`d) Data-Handlingfunction. Provides the ability to transfer code—elements between ports in the absence
`of a collision.
`
`c)
`
`e)
`
`f)
`
`g)
`
`Received Event-Handling requirement. Provides the ability to derive a carrier signal from the input
`signals presented to the ports.
`Collision-Handlingfimction. Provides the ability to detect the simultaneous reception of frames at
`two or more ports and then to propagate a Jam message to all connected ports.
`Error-Handlingfunction. Provides the ability to prevent substandard links from generating streams
`of false carrier and interfering with other links.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stang@_;,rd.
`
`0224
`
`it 1025
`
`Aerohive - Exhibit 1025
`
`0224
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`h)
`
`i)
`
`Partition function. Provides the ability to prevent a malfunctioning port from generating an exces-
`sive number of consecutive collisions and indefinitely disrupting data transmission on the network.
`Receive Jabberfimction. Provides the ability to interrupt the reception of abnormally long streams
`of input data.
`
`27.3.1 Repeater functions
`
`The repeater set shall provide the Signal Restoration, Transmit, Receive, Data Handling, Received Event
`Handling, Collision Handling, Error Handling, Partition, and Receive Jabber functions. The repeater is trans-
`parent to all network acquisition activity and to all DTEs. The repeater will not alter the basic fairness crite-
`rion for all DTEs to access the network or weigh it toward any DTE or group of DTEs regardless of network
`location.
`
`The Transmit and Receive functional requirements are specified by the PHY clauses, clause 23 for
`l0OBASE-T4 and clauses 24 to 26 for l00BASE-X.
`
`27.3.1.1 Signal restoration functional requirements
`
`27.3.1.1.1 Signal amplification
`
`The repeater set (including its integral PHYS) shall ensure that the amplitude characteristics of the signals at
`the MDI outputs of the repeater set are within the tolerances of the specification for the appropriate PHY
`type. Therefore, any loss of signal—to—noise ratio due to cable loss and noise pickup is regained at the output
`of the repeater set as long as the incoming data is within system specification.
`
`27.3.1.1.2 Signal wave-shape restoration
`
`The repeater set (including its integral PHYs) shall ensure that the wave-shape characteristics of the signals
`at the MDI outputs of a repeater set are within the specified tolerance for the appropriate PHY type. There-
`fore, any loss of wave-shape due to PHYS and media distortion is restored at the output of the repeater set.
`
`27.3.1.1.3 Signal retiming
`
`The repeater set (including its integral PHYS) shall ensure that the timing of the encoded data output at the
`MDI outputs of a repeater set are within the specified tolerance for the appropriate PHY type. Therefore, any
`receive jitter from the media is removed at the output of the repeater set.
`
`27.3.1.2 Data-handling functional requirements
`
`27.3.1.2.1 Data frame forwarding
`
`The repeater set shall ensure that the data frame received on a single input port is distributed to all other out-
`put ports in a manner appropriate for the PHY type of that port. The data frame is that portion of the packet
`afier the SFD and before the end-of-frame delimiter. The only exceptions to this rule are when contention
`exists among any of the ports, when the receive port is partitioned as defined in 27.3.1.6, when the receive
`port is in the Jabber state as defined in 27.3.1.7, or when the receive port is in the Link Unstable state as
`defined in 27.3.l.5.1. Between unpartitioned ports, the rules for collision handling (see 27.3.1.4) take prece-
`dence.
`
`27.3.1.2.2 Received code violations
`
`The repeater set shall ensure that any code violations received while forwarding a packet are propagated to
`all outgoing segments. These code violations shall be forwarded as received or replaced by bad_code (see
`23.2.1.2) or /H/ (see 24.2.2.1) code-groups, as appropriate for the outgoing PHY type. Once a received code
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0225
`
`"t 1025
`
`Aerohive - Exhibit 1025
`
`0225
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`violation has been replaced by bad_code or the /I-I/ code—group, this substitution shall continue for the
`remainder of the packet regardless of its content. The only exception to this rule is when contention exists
`among any of the ports, where the rules for collision handling (see 27.3.1.4) then take precedence.
`
`27.3.1.3 Received event-handling functional requirements
`
`27.3.1 .3.1 Received event handling
`
`For all its ports, the repeater set shall implement a fimction (scarrier_present) that represents a received
`event. Received events include both the data frame and any encapsulation of the data frame such as Pream-
`ble, SFD and the code—groups /H/, /J/, /K/, bad_code, eop, /T/, /R/, etc. A received event is exclusive of the
`IDLE pattern. Upon detection of scarrier_present from one port, the repeater set repeats all received signals
`in the data frame fi'om that port to the other port (or ports) as described in figure 27-2.
`
`27.3.1.3.2 Preamble regeneration
`
`The repeater set shall output preamble as appropriate for the outgoing PHY type followed by the SFD.
`
`27.3.1.3.3 Start-of-packet propagation delay
`
`The start-of-packet propagation delay for a repeater set is the time delay between the start of the packet (see
`24.6 and 23.11.3) on its repeated-fi‘om (input) port to the start of the packet on its repeated-to (output) port
`(or ports). This parameter is referred to as the SOP delay. The maximum value of this delay is constrained
`by table 27-2.
`
`27.3.1.3.4 Start-of-packet variability
`
`The start-of-packet variability for a repeater set is defined as the total worst-case difference between start-of-
`packet propagation delays for successive packets separated by 104 bit times (BT) or less at the same input
`port. The variability shall be less than or equal to those specified in table 27-1.
`
`Table 27-1 —Start-of-packet variability
`
`
`
`27.3.1.4 Collision-handling functional requirements
`
`27.3.1.4.1 Collision detection
`
`The repeater performs collision detection by monitoring all its enabled input ports for received events. When
`the repeater detects received events on more than one input port, it shall enter a collision state and transmit
`the Jam message to all of its output ports.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0226
`
`it 1025
`
`Aerohive - Exhibit 1025
`
`0226
`
`

`

`IEEE
`Std 802.3u-1995
`
`27.3.1 .4.2 Jam generation
`
`SUPPLEMENT TO 802.3:
`
`While a collision is occurring between any of its ports, the repeater unit shall transmit the Jam message to all
`of the PMAs to which it is connected. The Jam message shall be transmitted in accordance with the repeater
`state diagram in figure 27-4 and figure 27-5.
`
`27.3.1.4.3 Collision-jam propagation delay
`
`The start-of-collision Jam propagation delay for a repeater set is the time delay between the start of the sec-
`ond packet input signals to arrive at its port and the start of Jam (see 24.6 and 23.11) out on all ports. This
`parameter is referred to as the SO] delay. The delay shall be constrained by table 27-2.
`
`Table 27-2—Start-of-packet propagation and start-of-collision Jam propagation delays
`
`27.3.1.4.4 Cessation-of-collision Jam propagation delay
`
`The cessation-of-collision Jam propagation delay for a repeater set is the time delay between the end of the
`packet (sec 24.6 and 23.113) that creates a state such that Jam should end at a port and the end of Jam (sec
`24.6 and 23.113) at that port. The states of the input signals that should cause Jam to end are covered in
`detail in the repeater state diagrams. This parameter is referred to as the EOJ delay. The delay shall be con-
`strained by table 27-3.
`
`Table 27-3—Cessation-of-collision Jam propagation delay
`
`27.3.1.5 Error-handling functional requirements
`
`27.3.1.5.1 100BASE-X carrier integrity functional requirements
`
`In l00BASE-TX and 100BASE-FX systems, it is desirable that the repeater set protect the network fiom
`some transient fault conditions that would disrupt network communications. Potential likely causes of such
`conditions are DTE and repeater power-up and power-down transients, cable disconnects, and faulty wiring.
`
`Each l00BASE-TX and 100BASE-FX repeater PMA interface shall contain a self-interrupt capability, as
`described in figure 27-9, to prevent a segment’s spurious carrier activity from reaching the repeater unit and
`hence propagating through the network.
`
`The repeater PMA interface shall count consecutive false carrier events. A false carrier event is defined as a
`carrier event that does not begin with a valid start-of-stream delimiter (see 24.2.2.l.4). The count shall be
`incremented on each false carrier event and shall be reset on reception of a valid carrier event. In addition,
`each PMA interface shall contain a false carrier timer, which is enabled at the beginning of a false carrier
`event and reset at the conclusion of such an event. A repeater unit shall transmit the Jam message to all of the
`PMAs to which it is connected for the duration of the false carrier event or until the duration of the event
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`
`0227
`
`

`

`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`exceeds the time specified by the false_carrier_timer (see 27 .3.2.1.4), whichever is shorter. The Jam message
`shall be transmitted in accordance with the repeater state diagram in figure 27-4 and figure 27-5. The LINK
`UNSTABLE condition shall be detected when the False Carrier Count exceeds the value FCCLimit (see
`27.3.2.1.1) or the duration of a false carrier event exceeds the time specified by the false_carrier_timer. In
`addition, the LINK UNSTABLE condition shall be detected upon power-up reset.
`
`Upon detection of LINK UNSTABLE, the port shall perform the following:
`
`a)
`b)
`c)
`
`Inhibit sending further messages to the repeater unit.
`Inhibit sending further output messages from the repeater unit.
`Continue to monitor activity on that PMA interface.
`
`The repeater shall exit the LINK UNSTABLE condition when one of the following is met:
`
`a)
`
`The repeater has detected no activity (Idle) for more than the time specified by ipg_timer plus
`id1e_timer (see 27.3.2.1.4) on port X.
`b) A valid carrier event with a duration greater than the time specified by valid_carrier_timer (see
`27.3.2.1.4) has been received, preceded by no activity (Idle) for more than the time specified by
`ipg_timer (see 27.3.2.1.4) on port X.
`
`27.3.1.5.2 Speed handling
`
`If the PHY has the capability of detecting speeds other than 100 Mb/s, then the repeater set shall have the
`capability of blocking the flow of non-100 Mb/s signals. The incorporation of 100 Mb/s and 10 Mb/s
`repeater functionality within a single repeater set is beyond the scope of this standard.
`
`27.3.1.6 Partition functional requirements
`
`In large multisegment networks it may be desirable that the repeater set protect the network from some fault
`conditions that would disrupt network communications. A potentially likely cause of this condition could be
`due to a cable fault.
`
`Each repeater PMA interface shall contain a self-interrupt capability, as described in figure 27-8, to prevent a
`faulty segment’s carrier activity from reaching the repeater unit and hence propagating through the network.
`The repeater PMA interface shall count consecutive collisions. The count shall be incremented on each
`transmission that suffers a collision and shall be reset on a successful transmission. If this count exceeds the
`
`value CCLin1it (see 27.3.2.1.1) the Partition condition shall be detected.
`
`Upon detection of Partition, the port shall perform the following:
`
`a)
`b)
`c)
`
`Inhibit sending further input messages to the repeater unit.
`Continue to output messages from the repeater unit.
`Continue to monitor activity on that PMA interface.
`
`The repeater shall reset the Partition fi1nction when one of the following conditions is met:
`
`a)
`b)
`
`On power-up reset.
`The repeater has detected activity on the port for more than the number of bits specified for
`no_collision_tirner (see 27.3.2.1.4) without incurring a collision.
`
`27.3.1.7 Receive jabber functional requirements
`
`Each repeater PMA interface shall contain a self-interrupt capability, as described in figure 27-7, to prevent
`an illegally long reception of data fi'om reaching the repeater unit. The repeater PMA interface shall provide
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`Aerohive - Exhibit 1025
`
`0228
`
`

`

`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`a window of duration jabber_tirner bit times (see 27.3.2.1.4) during which the input messages may be passed
`on to other repeater unit functions. If a reception exceeds this duration, the jabber condition shall be
`detected.
`
`Upon detection ofjabber, the port shall perform the following:
`
`a)
`b)
`
`Inhibit sending filrther input messages to the repeater 11nit.
`Inhibit se