CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`|ink_status(X) at OK
`
`begin = true
`
`ipg_timer_done
`
`carrier_status(X) = ON
`
`id|e_timer_d0ne
`
`(rxerror_status(X) = ERROR) +
`((carrier_status(X) = OFF) *
`(valid_carrier_timer_not_done))
`
`(carrier_status(X) = OFF) *
`va|id_carrier_timer_done
`
`carrier_status(X) = ON
`
`carrier_status(X) = OFF
`
`rxerror_status(X) = ERROR
`
`(carrier_status(X) = o|=|=) *
`(FCC(X) < FCCLimit)
`
`fa|se_carrier_timer_done +
`((carrier_status(X) = OFF) *
`(FCC(X) = FCCLimit))
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0242
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`27.4 Repeater electrical specifications
`
`27.4.1 Electrical isolation
`
`Network segments that have different isolation and grounding requirements shall have those requirements
`provided by the port-to-port isolation of the repeater set.
`
`27.5 Environmental specifications
`
`27.5.1 General safety
`
`All equipment meeting this standard shall conform to IEC 950: 1991.
`
`27.5.2 Network safety
`
`This subclause sets forth a number of recommendations and guidelines related to safety concerns; the list is
`neither complete nor does it address all possible safety issues. The designer is urged to consult the relevant
`local, national, and international safety regulations to ensure compliance with the appropriate requirements.
`
`LAN cable systems described in this subclause are subject to at least four direct electrical safety hazards dur-
`ing their installation and use. These hazards are as follows:
`
`Direct contact between LAN components and power, lighting, or communications circuits.
`a)
`Static charge buildup on LAN cables and components.
`b)
`c) High-energy transients coupled onto the LAN cable system.
`d)
`Voltage potential differences between safety grounds to which the various LAN components are
`connected.
`
`Such electrical safety hazards must be avoided or appropriately protected against for proper network instal-
`lation and performance. In addition to provisions for proper handling of these conditions in an operational
`system, special measures must be taken to ensure that the intended safety features are not negated during
`installation of a new network or during modification or maintenance of an existing network. Isolation
`requirements are defined in 27.5.3.
`
`27.5.2.1 Installation
`
`Sound installation practice, as defined by applicable local codes and regulations, shall be followed in every
`instance m which such practice is applicable.
`
`27.5.2.2 Grounding
`
`The safety ground, or chassis ground for the repeater set, shall be provided through the main ac power cord
`via the third wire ground as defined by applicable local codes and regulations. It is recommended that an
`external PHY to the repeater should also be mechanically grounded to the repeater unit through the power
`and ground signals in the lV[II connection and via the metal shell and shield of the M11 connector if available.
`
`If the MDI connector should provide a shield connection, the shield may be connected to the repeater safety
`ground. A network segment connected to the repeater set through the MDI may use a shield. If both ends of
`the network segment have a shielded MDI connector available, then the shield may be grounded at both ends
`according to local regulations and ISO/IEC 11801: 1995, and as long as the ground potential difference
`between both ends of the network segment is less than 1V ms. The same rules apply towards an inter-
`repeater link between two repeaters. Multiple repeaters should reside on the same power main; if not, then it
`is highly recommended that the repeaters be connected via fiber.
`
`This is anzélrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0243
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`WARNING—It is assumed that the equipment to which the repeater is attached is properly grounded and not lefi float-
`ing nor serviced by a “doubly insulated ac power distribution system.” The use of floating or insulated equipment, and
`the consequent implications for safety, are beyond the scope of this standard.
`
`27.5.2.3 Installation and maintenance guidelines
`
`Dining installation and maintenance of the cable plant, care should be taken to ensure that uninsulated net-
`work cable connectors do not make electrical contact with unintended conductors or ground.
`
`27.5.3 Electrical isolation
`
`There are two electrical power distribution environments to be considered that require different electrical
`isolation properties:
`
`a)
`
`b)
`
`Environment A. When a LAN or LAN segment, with all its associated interconnected equipment, is
`entirely contained within a single low-voltage power distribution system and within a single building.
`Environment B. When a LAN crosses the boundary between separate power distribution systems or
`the boundary of a single building.
`
`27.5.3.1 Environment A requirements
`
`Attachment of network segments via repeater sets requires electrical isolation of 500V rrns, one-minute
`withstand, between the segment and the protective ground of the repeater unit.
`
`27.5.3.2 Environment B requirements
`
`The attachment of network segments that cross environment B boundaries requires electrical isolation of
`1500 V rrns, one-minute withstand, between each segment and all other attached segments and also the pro-
`tective ground of the repeater unit.
`
`The requirements for interconnected electrically conducting LAN segments that are partially or fully exter-
`nal to a single building environment may require additional protection against lightning strike hazards. Such
`requirements are beyond the scope of this standard. It is recommended that the above situation be handled by
`the use of nonelectrically conducting segments (e.g., fiber optic).
`
`It is assumed that any nonelectrically conducting segments will provide sufficient isolation within that media
`to satisfy the isolation requirements of environment B.
`
`27.5.4 Reliability
`
`A two-port repeater set shall be designed to provide a mean time between failure (MTBF) of at least 50 000
`hours of continuous operation without causing a communications failure among stations attached to the net-
`work medium. Repeater sets with more than two ports shall add no more than 3.46 X 10‘5 failures per hour
`for each additional port.
`
`The repeater set electronics should be designed to minimize the probability of component failures within the
`repeater electronics that prevent communications among other PHYS on the individual segments. Connec-
`tors and other passive components comprising the means of connecting the repeater to the cable should be
`designed to minimize the probability of total network failure.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0244
`
`

`
`IEEE
`Std 802.3u-1995
`
`27.5.5 Environment
`
`27.5.5.1 Electromagnetic emission
`
`SUPPLEMENT TO 802.3:
`
`The repeater shall comply with applicable local and national codes for the limitation of electromagnetic
`interference.
`
`27.5.5.2 Temperature and humidity
`
`The repeater is expected to operate over a reasonable range of environmental conditions related to tempera-
`ture, humidity, and physical handling (such as shock and Vibration). Specific requirements and values for
`these parameters are considered to be beyond the scope of this standard.
`
`It is recommended that manufacturers indicate in the literature associated with the repeater the operating
`environmental conditions to facilitate selection, installation, and maintenance.
`
`27.6 Repeater labeling
`
`It is required that each repeater (and supporting documentation) shall be labeled in a manner visible to the
`user with these parameters:
`
`a)
`b)
`
`Crossover ports appropriate to the respective PHY should be marked with an X.
`The repeater set class type should be labeled in the following manner:
`1) Class I: a Roman numeral “I” centered within a circle.
`2) Class II: a Roman numeral “II” centered within a circle.
`
`Additionally it is recommended that each repeater (and supporting documentation) also be labeled in a man-
`ner visible to the user with at least these parameters:
`
`a) Data rate capability in Mb/s
`b) Any applicable safety warnings
`c)
`Port type, i.e., l00BASE-TX and 100BASE-T4
`d) Worst—case bit time delays between any two ports appropriate for
`1)
`Start-of-packet propagation delay
`2)
`Start-of-collision Jam propagation delay
`3) Cessation-of-collision Jam propagation delay
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0245
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`27.7 Protocol Implementation Conformance Statement (PICS) profonna for clause 27,
`Repeater for 100 Mbls baseband networks“
`
`27.7.1 Introduction
`
`The supplier of a protocol implementation that is claimed to conform to IEEE Std 802.3u-1995, Repeater for
`100 Mb/s baseband networks, shall complete the following Protocol Implementation Conformance State-
`ment (PICS) proforma.
`
`27.7.2 Identification
`
`27.7.2.1 Implementation identification
`
`
`
`27.7.2.2 Protocol summary
`
`
`
`26Capyright releasefor PICSpmformas Users of this standard may fi'ee1y 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 stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0246
`
`

`
`IEEE
`Std 802.3u-1995
`
`27.7.3 Major capabilitiesloptions
`
`SUPPLEMENT TO 802.3:
`
`Subclause
`
`Value/Comment
`
`Repeater supports
`IOOBASEFX connections
`
`27.1.2.2
`
`Repeater supports
`IOOBASETX connections
`
`Repeater supports
`IOOBASET4 connections
`
`27.1.2.2
`
`27.1.2.2
`
`IOOBASE-T signals
`
`Repeater meets Class I delays
`
`27.1.1.3
`
`Repeater meets Class II delays
`
`27.1.1.3
`
`PHYS capable of detecting non
`
`27.3.1.5.2
`
`In addition, the following predicate name is defined for use when different implementations from the set
`above have common parameters:
`
`*XP:FXP or TXP
`
`27.7.4 PICS proforma tables for the Repeater for 100 Mbls baseband networks
`
`27.7.4.1 Compatibility considerations
`
`Subclause
`
`Value/Comment
`
`implemented
`
`100BASE-FX port compatible
`at the MDI
`
`27.1.2.2
`
`IOOBASE-TX port compatible
`at the MDI
`
`27.1.2.2
`
`IOOBASE-T4 port compatible
`at the MDI
`
`27.1.2.2
`
`Internal segment compatibility
`
`27.1.2.2.1
`
`Internal port meets clause 29
`when repeater management
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0247
`
`Aerohive - Exhibit 1025
`0247
`
`

`
`CSMA/CD
`
`27.7.4.2 Repeater functions
`
`IEEE
`Std 802.3u-1995
`
`Subclause
`
`Value/Comment
`
`Signal Restoration
`
`Data Handling
`
`Received Event Handling
`
`Received Jabber
`
`Collision Handling
`
`Error Handling
`
`Partition
`
`27.7.4.3 Signal restoration function
`
`Subclause
`
`Value/Comment
`
`Output amplitude as required
`by l00BASE-FX
`
`Output amplitude as required
`by IOOBASE-TX
`
`Output amplitude as required
`by IOOBASE-T4
`
`Output signal wave-shape as
`required by l00BASE-FX
`
`Output signal wave-shape as
`required by IOOBASE-TX
`
`Output signal wave-shape as
`required by IOOBASE-T4
`
`27.3.1.1.l
`
`27.3.1.1.1
`
`27.3.1.1.1
`
`27.3.1.1.2
`
`27.3.1.1.2
`
`27.3.1.1.2
`
`Output data timing as required
`by l00BASE-FX
`
`27.3.1.1.3
`
`Output data timing as required
`by IOOBASE-TX
`
`27.3.1.1.3
`
`Output data timing as required
`by IOOBASE-T4
`
`27.3.1.1.3
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`Aerohive - Exhibit 1025
`
`0248
`
`Aerohive - Exhibit 1025
`0248
`
`

`
`SUPPLEMENT TO 802.3:
`
`Value/Comment
`
`IEEE
`Std 802.3u-1995
`
`27.7.4.4 Data-Handling function
`
`Data frames forwarded to all
`ports except receiving port
`
`Data frames transmitted as
`appropriate for l00BASE-FX
`
`Data frames transmitted as
`appropriate for IOOBASE-TX
`
`Data frames transmitted as
`appropriate for l00BASE-T4
`
`Code Violations forwarded to
`all transmitting ports
`
`Code Violations forwarded as
`received
`
`Received Code Violation for-
`warded as /H/ or as received
`
`Received Code Violation for-
`warded as bad_code or as
`received
`
`Code element substitution for
`remainder of packet after
`received Code Violation
`
`Subclause
`
`27.3.1.2.1
`
`27.3.1.2.l
`
`27.3.l.2.1
`
`27.3.l.2.l
`
`27.3.1.2.2
`
`27.3.1.2.2
`
`27.3.l.2.2
`
`27.3.1.2.2
`
`27.3.l.2.2
`
`27.7.4.5 Receive Event-Handling function
`
`Feature
`
`Subclause
`
`Value/Comment
`
`scarrier_present detect imple-
`mented
`
`27.3.l.3.l
`
`delay, Class II repeater
`
`Repeat all received signals
`
`27.3.l.3.l
`
`Preamble encoded as required
`by l00BASE-FX
`
`Preamble encoded as required
`by IOOBASE-TX
`
`27.3.1.3.2
`
`27.3.l.3.2
`
`Preamble encoded as required
`by l00BASE-T4
`
`27.3.l.3.2
`
`Start-of-packet propagation
`delay, Class I repeater
`
`27.3.l.3.3
`
`Start-of-packet propagation
`
`27.3.1.3.3
`
`This is anzggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0249
`
`Aerohive - Exhibit 1025
`0249
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0250
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`27.7.4.6 Collision-Handling function
`
`Subclause
`
`Value/Comment
`
`Collision Detection
`
`27.3.l.4.l
`
`Receive event on more than
`one port
`
`Transmit Jam message while
`collision is detected
`
`SOP + SOJ S 140 BT
`
`SOP + SOJ S 67 BT
`
`SOP S 46, SO] S 46 BT
`
`EOJ S SOP
`
`EOJ S SOP
`
`Jam Generation
`
`Collision-Jam Propagation
`delay, Class I repeater.
`
`Collision-Jam Propagation
`delay, Class II repeater with
`any port T4
`
`Collision-Jam Propagation
`delay, Class II repeater, all TX/
`FX ports
`
`Cessation of Collision Propa-
`gation delay, Class I repeater
`
`Cessation of Collision Propa-
`gation delay, Class II repeater
`
`27.3.1 .4.2
`
`27.3.1.4.3
`
`27.3.l.4.3
`
`27.3.1.4.3
`
`27.3.l.4.4
`
`27.3.1 .4.4
`
`27.7.4.7 Error-Handling function
`
`Carrier Integrity function
`implementation
`
`False carrier count for Link
`Unstable detection
`
`False carrier count reset
`
`False carrier timer for Link
`Unstable detection
`
`Jam message duration
`
`Subclause
`
`27.3.1.5.l
`
`27.3.1.5.l
`
`27.3.1.5.l
`
`27.3.1.5.l
`
`27.3.1.5.l
`
`Link Unstable detection
`
`27.3.1.5.l
`
`Messages sent to repeater unit
`in Link Unstable state
`
`Messages sent from repeater
`unit in Link Unstable state
`
`27.3.1.5.l
`
`27.3.1.5.l
`
`Value/Comment
`
`Self-interrupt of data reception
`
`False carrier count in excess of
`FCCLimit
`
`Count reset on valid carrier
`
`False carrier of length in
`excess of false_carrier_timer
`
`Equals duration of false carrier
`event, but not greater than
`duration of false_carrier_timer
`
`False Carrier count exceed
`FCCLimit or False carrier
`exceeds the false_carrier_timer
`or power-up reset
`
`Inhibited sending messages to
`repeater unit
`
`Inhibited sending output mes-
`sages
`
`This is anzggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`025 1
`
`Aerohive - Exhibit 1025
`0251
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0252
`
`

`
`IEEE
`Std 802.3u-1995
`
`27.7.4.8 Partition function
`
`SUPPLEMENT TO 802.3:
`
`Subclause
`
`Value/Comment
`
`Partition function implementa-
`tion
`
`Consecutive collision count for
`entry into partition state
`
`Consecutive collision counter
`incrementing
`
`Consecutive collision counter
`reset
`
`Messages sent to repeater unit
`in Partition state
`
`Messages sent from repeater
`unit ir1 Partition state
`
`Monitoring activity on PMA
`interface in Partition state
`
`Reset of Partition state
`
`Self-interrupt of data reception
`
`Consecutive collision in excess
`of CCLimit
`
`Count incremented on each
`transmission that suffers a col-
`lision
`
`Count reset on successful colli-
`sion
`
`Inhibited sending messages to
`repeater unit
`
`Continue sending output mes-
`sages
`
`Continue monitoring activity at
`PMA interface
`
`Power-up reset or Detecting
`activity for greater than dura-
`tion no_collision_timer with-
`out a collision
`
`27.7.4.9 Receive Jabber function
`
`Subclause
`
`Value/Comment
`
`longer detected
`
`Receive Jabber function imple-
`mentation
`
`Excessive receive duration
`timer for Receive Jabber detec-
`tion
`
`Messages sent to repeater unit
`in Receive Jabber state
`
`Messages sent from repeater
`unit in Receive Jabber state
`
`Reset of Receive Jabber state
`
`Self-interrupt of data reception
`
`Reception duration in excess of
`jabber_timer
`
`Inhibit sending input mes-
`sages to repeater unit
`
`Inhibit sending output mes-
`sages
`
`Power-up reset or Carrier no
`
`This is anzgxrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`025 3
`
`Aerohive - Exhibit 1025
`0253
`
`

`
`CSMA/CD
`
`27.7.4.10 Repeater state diagrams
`
`IEEE
`Std 802.3u-1995
`
`Subclause
`
`Value/Comment
`
`Repeater core state diagram
`
`Receive state diagram for
`port X
`
`100BASE-TX and 100BASE-
`FX Transmit state diagram for
`port X
`
`l00BASE-T4 Transmit state
`diagram for port X
`
`Repeater data-handler state
`diagram
`
`Receive timer for port X state
`diagram
`
`Repeater partition state dia-
`gram for port X
`
`Carrier integrity monitor for
`port X state diagram
`
`\/Ieets the requirements of
`figure 27-2
`
`Vleets the requirements of
`figure 27-3
`
`Vleets the requirements of
`figure 27-4
`
`Vleets the requirements of
`figure 27-5
`
`Vleets the requirements of
`figure 27-6
`
`Vleets the requirements of
`figure 27-7
`
`Meets the requirements of
`figure 27-8
`
`Meets the requirements of
`figure 27-9
`
`27.7.4.1 1 Repeater electrical
`
`Feature
`
`Subclause
`
`Value/Comment
`
`codes
`
`Satisfies isolation and ground-
`ing requirements for attached
`network segments
`
`IEC 950: 1991
`
`Sound, as defined by local
`code and regulations
`
`Chassis ground provided
`through ac mains cord
`
`At least 50 000 hours
`
`No more than 3.46 X 10‘6
`increase in failures per hour
`
`Comply with local or national
`
`Port-to-port isolation
`
`Safety
`
`Installation practices
`
`Grounding
`
`2-port repeater set MTBF
`
`Additional port effect on
`MTBF
`
`Electromagnetic interference
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`Aerohive - Exhibit 1025
`
`0254
`
`Aerohive - Exhibit 1025
`0254
`
`

`
`CSMA/CD
`
`27.7.4.12 Repeater labeling
`
`IEEE
`Std 802.3u-1995
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggyd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0255
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`28. Physical Layer link signaling for 10 Mbls and 100 Mbls Auto-Negotiation
`on twisted pair
`
`28.1 Overview
`
`28.1.1 Scope
`
`Clause 28 describes the Auto-Negotiation function that allows a device to advertise enhanced modes of oper-
`ation it possesses to a device at the remote end of a link segment and to detect corresponding enhanced oper-
`ational modes that the other device may be advertising.
`
`The objective of the Auto-Negotiation function is to provide the means to exchange information between
`two devices that share a link segment and to automatically configure both devices to take maximum advan-
`tage of their abilities. Auto-Negotiation is performed using a modified IOBASE-T link integrity test pulse
`sequence, such that no packet or upper layer protocol overhead is added to the network devices (see figure
`28-1). Auto-Negotiation does not test the link segment characteristics (see 28.1.4).
`
`The function allows the devices at both ends of a link segment to advertise abilities, acknowledge receipt and
`understanding of the common mode(s) of operation that both devices share, and to reject the use of opera-
`tional modes that are not shared by both devices. Where more than one common mode exists between the
`two devices, a mechanism is provided to allow the devices to resolve to a single mode of operation using a
`predetermined priority resolution function. The Auto-Negotiation function allows the devices to switch
`between the various operational modes in an ordered fashion, permits management to disable or enable the
`Auto-Negotiation filnction, and allows management to select a specific operational mode. The Auto-Negoti-
`ation function also provides a Parallel Detection function to allow 10BASE—T,
`lO0BASE-TX, and
`IOOBASE-T4 compatible devices to be recognized, even though they may not provide Auto-Negotiation.
`
`§§
`
`The basic mechanism to achieve Auto-Negotiation is to pass information encapsulated within a burst of
`closely spaced link integrity test pulses that individually meet the IOBASE-T Transmitter Wavefonn for
`Link Test Pulse (figure 14-12). This burst of pulses is referred to as a Fast Link Pulse (FLP) Burst. Each
`device capable ofAuto-Negotiation issues FLP Bursts at power up, on command fi'om management, or due
`to user interaction. The FLP Burst consists of a series of link integrity test pulses that form an alternating
`clock/data sequence. Extraction of the data bits from the FLP Burst yields a Link Code Word that identifies
`the operational modes supported by the remote device, as well as some information used for the Auto-Nego-
`tiation fi1nction’s handshake mechanism.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0256
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`To maintain interoperability with existing 10BASE-T devices, the function also supports the reception of
`10BASE-T compliant link integrity test pulses. 10BASE-T link pulse activity is referred to as the Normal
`Link Pulse (NLP) sequence and is defined in 14.2.1.1. A device that fails to respond to the FLP Burst
`sequence by returning only the NLP sequence is treated as a 10BASE-T compatible device.
`
`28.1.2 Application perspectivelobjectives
`
`The Auto—Negotiation function is designed to be expandable and allow IEEE 802.3 compatible devices using
`an eight—pin modular connector to self-configure a jointly compatible operating mode. Implementation of
`the Auto—Negotiation function is optional. However, it is highly recommended that this method alone be uti-
`lized to perform the negotiation of the link operation.
`
`The following are the objectives ofAuto—Negotiation:
`
`a) Must interoperate with the IEEE 802.3 10BASE-T installed base.
`b) Must allow automatic upgrade from the 10BASE-T mode to the desired “High-Perforrnance Mode.”
`c)
`Requires that the 10BASE-T data service is the Lowest Common Denominator (LCD) that can be
`resolved. A 10BASE-T PMA is not required to be implemented, however. Only the NLP Receive
`Link Integrity Test function is required.
`Reasonable and cost-efl'ective to implement.
`d)
`e) Must provide a sufficiently extensible code space to
`1) Meet existing and future requirements.
`2) Allow simple extension without impacting the installed base.
`3) Accommodate remote fault signals.
`4) Accommodate link partner ability detection.
`f) Must allow manual or Network Management configuration to override the Auto—Negotiation.
`g) Must be capable of operation in the absence of Network Management.
`h) Must not preclude the ability to negotiate “back” to the 10BASE-T operational mode.
`i) Must operate when
`1)
`The link is initially electrically connected.
`2) A device at either end of the link is powered up, reset, or a renegotiation request is made.
`The Auto—Negotiation function may be enabled by automatic, manual, or Network Management
`intervention.
`
`j)
`
`Completes the base page Auto—Negotiation fimction in a bounded time period.
`k)
`1) Will provide the basis for the link establishment process in future CSMA/CD compatible LAN stan-
`dards that use an eight—pin modular connector.
`m) Must not cause corruption of IEEE 802.3 Layer Management statistics.
`11)
`Operates using a peer-to-peer exchange of information with no requirement for a master device (not
`master—slave).
`0) Must be robust in the UTP cable noise environment.
`p) Must not significantly impact EMI/RFI emissions.
`
`28.1.3 Relationship to ISOIIEC 8802-3
`
`The Auto—Negotiation function is provided at the Physical Layer of the OSI reference model as shown in fig-
`ure 28-2. Devices that support multiple modes of operation may advertise this fact using this function. The
`actual transfer of information of ability is observable only at the MDI or on the medium. Auto—Negotiation
`signaling does not occur across either the AUI or MII. Control of the Auto—Negotiation fl.lI1Ctl0Il may be sup-
`ported through the Management Interface of the MII or equivalent. If an explicit embodiment of the MII is
`supported, the control and status registers to support the Auto—Negotiation fimction shall be implemented in
`accordance with the definitions in clause 22 and 28.2.4. If a physical embodiment of the MII management is
`not present, then it is strongly recommended that the implementation provide control and status mechanisms
`equivalent to those described in clause 22 and 28.2.4 for manual and/or management interaction.
`
`This is anzggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0257
`
`

`
`CSMNCD
`
`IEEE
`Std Bl]2_3u—1995
`
`OSI
`REFERENCE
`MODEL
`LAYERS
`
`AF'F’L|CAT|0N
`
`LAN
`CSMNCD
`LAYERS
`
`HIGH ER LAYERS
`
`PRESENTATION
`
`LLC—LOGlCAL LINK CONTROL
`
`SESSION
`
`MA.C—MED|A ACCESS CONTROL
`
`TRANSPOR'r
`NETWORK
`
`II
`
`"I
`
`DATA LINK
`PHYSICAL
`
`RECOFCIHIATION
`‘Mil ——’v
`
`PCS
`
`PMA
`
`MEDIUM
`
`IDIJ MEN'S
`
`MDI = MEDIUM DEPENDENT INTERFACE
`MII = MEDIA INDEPENDENT INTERFACE
`AUTONEG = AUTO-NEGOTIATION
`
`PCS = PHYSICAL CODING SUBLAYER
`PMA = PHYSICAL MEDIUM ATTACHMENT
`PHY = PHYSICAL LAYER DEVICE
`PMD = PHYSICAL MEDIUM DEPENDENT
`
`‘ MII is optional for 10 Mbis DTEs and For 100 Minis systems and is not specified for 1 Mints systems.
`'* PMD is specified for 100E!ASE—X only; 1Dl1|BASE—T4 does not use this layer.
`“* AUTONEG communicates with the PMA suniayeruirougn the PMA seniioe interface
`messages PMA_LlNK_request and PMA_L|NK.indicate.
`
`Figure 28-2—Location of Auto-Negotiation function within the ISO reference model
`
`28.1.4 Compatibility considerations
`
`The Auto-Negotiation function is designed to be completely backwards compatible and interoperable with
`IOBASE-T compliant devices. In order to achieve this, a device supporting the Auto-Negotiation function
`must provide the NLP Receive Link Integrity Test function as defined in figure 28-17. The Auto-Negotiation
`function also supports connection to IOOBASE-TX and IOOBASE-T4 devices without Auto-Negotiation
`through the Parallel Detection function. Connection to technologies other than 10BASE—T_. IOOBASE-TX,
`or 100BASE—T4 that do not incorporate Auto—Negotiation is not supported.
`
`Implementation ofthe Auto-Negotiation function is optional. For CSMAJCD compatible devices that use the
`eight-pin modular connector of ISOHIEC 8877: 1992 and that also encompass multiple operational modes. if
`a signaling method is used to automatically configure the preferred mode of operation, then the Auto-Nego-
`tiation function shall be used in compliance with clause 28. If the device uses IOBASE-T compatible link
`sigialing to advertise non-CSMAECD abilities, the device shall implement the Auto-Negotiation function as
`administered by this specification. All future CSMAICD iniplenientations that use an eight-pin modular
`connector shall be interoperable with devices supporting clause 28. If the implementor of a non-CSMAJCD
`eight-pin modular device wishes to assure that its operation does not conflict with CSMAICD devices, then
`adherence to clause 28 is recommended.
`
`While this Auto-Negotiation function must be implemented in CSMAJCD compatible devices that utilize the
`eight-pin modular connector. encompass multiple operational modes. and offer an Auto-Negotiation mecha-
`nism, the use of this function does not mandate that the IOBASE-T packet data communication service must
`
`This is an Archive IEEE Standard.
`
`it has been superseded by a later version of this stanglgagrd.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0258
`
`

`
`IEEE
`Std B02.3u-1995
`
`SUPPLEMENT TO 302.3:
`
`exist. A device that employs this function must support the 10BASE-T Link Integrity Test function through
`the NLP Receive Link Integrity Test state diagram. The device may also need to support other technology-
`dependent link test functions depending on the modes supported. Auto-Negotiation does not perform cable
`tests, such as detect number of conductor pairs (if more than two pairs are required) or cable performance
`measurements. Some PHYs that explicitly require use of high-perforrnance cables, may require knowledge
`of the cable type, or additional robustness tests (such as monitoring CRC or framing errors) to determine if
`the link segment is adequate.
`
`28.1.4.1 Interoperability with existing 10BASE-T devices
`
`During Auto-Negotiation, FLP Bursts separated by 16 :l: 8 ms are transmitted. The FLP Burst itself is a
`series of pulses separated by 62.5 :l: 7 us. The timing of FLP Bursts will cause a 10BASE-T device that is in
`the LINK TEST PASS state to remain in the LINK TEST PASS state while receiving FLP Bursts. An Auto-
`Negotiation able device must recognize the NLP sequence from a 10BASE-T Link Partner, cease transmis-
`sion of FLP Bursts, and enable the 10BASE-T PMA, if present. If the NLP sequence is detected and if the
`Auto-Negotiation able device does not have a 10BASE-T PMA, it will cease transmission of FLP Bursts,
`forcing the 10BASE-T Link Partner into the LINK TEST FAIL state(s) as indicated in figure 14-6.
`
`NOTE—Auto-Negotiation does not support the transmission of the NLP sequence. The 10BASE-T PMA provides this
`function if it is connected to the MDI. In the case where an Auto-Negotiation able device without a 10BASE-T PMA is
`connected to a 10BASE-T device without Auto-Negotiation, the NLP sequence is not transmitted because the Auto-
`Negotiation function has no 10BASE-T PMA to enable that can transmit the NLP sequence.
`
`28.1.4.2 Interoperability with Auto-Negotiation compatible devices
`
`An Auto-Negotiation compatible device decodes the base Link Code Word from the FLP Burst, and exam-
`ines the contents for the highest common ability that both devices share. Both devices acknowledge correct
`receipt of each other’s base Link Code Words by responding with FLP Bursts containing the Acknowledge
`Bit set. After both devices complete aclmowledgment, and optionally, Next Page exchange, both devices
`enable the highest common mode negotiated. The highest common mode is resolved using the priority reso-
`lution hierarchy specified in annex 28B. It may subsequently be the responsibility of a technology-dependent
`link integrity test function to verify operation of the link prior to enabling the data service.
`
`28.1.4.3 Cabling compatibility with Auto-Negotiation
`
`Provision has been made within Auto-Negotiation to limit the resulting link configuration in situations
`where the cabling may not support the highest common capability of the two end points. The system admin-
`istrator/installer must take the cabling capability into consideration when configuring a hub port’s advertised
`capability. That is, the advertised capability of a hub port should not result in an operational mode that is not
`compatible with the cabling.
`
`28.2 Functional specifications
`
`The Auto-Negotiation function provides a mechanism to control connection of a single MDI to a single
`PMA type, where more than one PMA type may exist. Management may provide additional control ofAuto-
`Negotiation through the Management fimction, but the presence of a management agent is not required.
`
`The Auto-Negotiation fimction shall provide the Auto-Negotiation Transmit, Receive, Arbitration, and NLP
`Receive Link Integrity Test fimctions and comply with the state diagrams of figures 28-14 to 28-17. The
`Auto-Negotiation functions shall interact with the technology-dependent PMAs through the Technology-
`Dependent Interface. Technology-dependent PMAs include, but are not limited to,
`l00BASE-TX and
`IOOBASE-T4. Technology-dependent link integrity test functions shall be implemented and interfaced to
`only if the device supports the given technology. For example, a 10BASE-T and l00BASE-TX Auto-Negoti-
`ation able device must implement and interface to the l00BASE-TX PMA/link integrity test fimction, but
`
`This is anzggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0259
`
`

`
`CSMA/CD
`
`IEEE
`Std 8D2.3u-1995
`
`does not need to include the IOOBASE-T4 PMA/Link Integrity Test fiinction. The Auto-Negotiation function
`shall provide an optional Management function that provides a control and status mechanism.
`
`28.2.1 Transmit function requirements
`
`The Transmit function provides the ability to transmit FLP Bursts. The first FLP Bursts exchanged by the
`Local Device and its Link Partner after Power-On, link restart, or renegotiation contain the base Link Code
`Word defined in 28.2.1.2. The Local Device may modify the Link Code Word to disable an ability it pos-
`sesses, b