CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`28.5.4.6 Management function requirements
`
`Mandatory MII registers for
`Auto-Negotiation
`
`Optional MII register for Auto-
`Negotiation
`
`Auto-Negotiation enable
`
`Manual Speed/Duplex settings
`
`Subclause
`
`28.2.4.1
`
`28.2.4.1
`
`28.2.4.] .1
`
`28.2.4. 1 .1
`
`control register (register 0)
`Restart Auto-Negotiation (0.9)
`default
`
`control register (register 0)
`Restart Auto-Negotiation (0.9)
`set
`
`control register (register 0)
`Restart Auto-Negotiation (0.9)
`reset
`
`status register (register 1)
`Auto-Negotiation Complete
`(1.5) reset
`
`status register (register 1)
`Remote Fault (1.4)
`
`advertisement register power
`on default
`
`link partner ability register
`read/write
`
`link partner ability register bit
`definitions
`
`status register (register 1)
`Auto-Negotiation Complete
`(1.5) set
`
`Auto-Negotiation expansion
`register (register 6)
`
`Link Partner Auto-Negotiation
`Able bit (6.0)
`
`28.2.4.l.l
`
`28.2.4.l.l
`
`28.2.4.l.l
`
`28.2.4.l.2
`
`28.2.4.l.2
`
`28.2.4.l.3
`
`28.2.4.l.4
`
`28.2.4.l.4
`
`28.2.4.l.4
`
`28.2.4.l.5
`
`28.2.4.l.5
`
`Value/comment
`
`Registers 0, 1, 4, 5, 6
`
`Register 7
`
`Set control register Auto-
`Negotiation Enable bit (0.12)
`
`When bit 0.12 set, control reg-
`ister Speed Detection (0.13)
`and Duplex Mode (0.8) are
`ignored, and the Auto-Negotia-
`tion function determines link
`configuration
`
`PHY returns Value of one in
`0.9 until Auto-Negotiation has
`been initiated
`
`When 0.9 set, Auto-Negotia-
`tion will (re)initiate. On com-
`pletion, 0.9 will be reset by the
`PHY device. Writing a zero to
`0.9 at any time has no effect
`
`0.9 is self-clearing; writing a
`zero to 0.9 at any time has no
`effect
`
`If bit 0.12 reset, or a PHY
`lacks the ability to perform
`Auto-Negotiation, (1.5) is reset
`
`Set by the PHY and remains
`set until either the status regis-
`ter is read or the PHY is reset
`
`Selector field as defined in
`annex 28A; Ack=0; Technol-
`ogy Ability Field based on MII
`status register (l.15:l 1) or log-
`ical equivalent
`
`Read only; write has no effect
`
`Direct representation of the
`received Link Code Word (fig-
`ure 28-7)
`
`Set to logic one upon success-
`ful completion of Auto-Negoti-
`ation
`
`Read only; write has no effect
`
`Set to indicate that the Link
`Partner is able to participate in
`the Auto-Negotiation function
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0296
`
`Aerohive - Exhibit 1025
`0296
`
`

`
`IEEE
`Std 802.3u-1995
`
`Page Received bit (6.1) set
`
`Subclause
`
`28.2.4.l.5
`
`Page Received bit (6.1) reset
`
`28.2.4.l.5
`
`28.2.4.1.5
`
`28.2.4.l.5
`
`28.2.4.l.5
`
`28.2.4.l.5
`
`28.2.4.1.6
`
`28.2.4.l.6
`
`28.2.5
`
`The Next Page Able bit (6.2)
`set
`
`The Link Partner Next Page
`Able bit (6.3) set
`
`Parallel Detection Fault bit
`(6.4) set
`
`Parallel Detection Fault bit
`(6.4) reset
`
`Next Page Transmit register
`default
`
`Write to Next Page Transmit
`register
`
`Absence of management
`function
`
`Next Page support in absence
`of MII management
`
`SUPPLEMENT TO 802.3:
`
`Value/comment
`
`Set to indicate that a new Link
`Code Word has been received
`and stored in the Auto-Neg0ti-
`ation link partner ability
`register
`
`Reset on a read of the Auto-
`Negotiation expansion register
`(register 6)
`
`Set to indicate that the Local
`Device supports the Next Page
`function
`
`Set to indicate that the Link
`Partner supports the Next Page
`function
`
`Set to indicate that zero or
`more than one of the NLP
`
`Receive Link Integrity Test
`function, IOOBASE-TX, or
`l00BASE-T4 PMAS have indi-
`cated link_status=READY
`when the autoneg_wait_timer
`expires
`
`Reset on a read of the Auto-
`Negotiation expansion register
`(register 6)
`
`On power-up, contains value of
`2001 H
`
`n1r_next_page_loaded set to
`true
`
`Advertised abilities provided
`through a logical equivalent of
`n1r_adv_ability[ l 6: l ]
`
`Device must provide logical
`equivalent of mr_np_able,
`rr1r_lp_np_able, or
`rr1r_next_page_loaded vari-
`ables in order to set NP bit in
`transmitted Link Code Word
`
`This is anzfirchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0297
`
`Aerohive - Exhibit 1025
`0297
`
`

`
`CSMA/CD
`
`28.5.4.7 Technology-dependent interface
`
`Subclause
`
`28.2.6.1.1
`
`28.2.6.1.2
`
`28.2.6.l.3
`
`28.2.6.1.3
`
`28.2.6.2.1
`
`28.2.6.2.1
`
`28.2.6.2.1
`
`28.2.6.2.2
`
`28.2.6.2.2
`
`PMA_LINK.indicate
`(link_status) values
`
`PMA_LINK.indi-
`cate(link_status) generation
`
`PMA_LINK.indi-
`cate(link_status), effect of
`receipt
`
`PMA_LINK.request(link_cont
`rol) values
`
`Effect of
`link_control=SCAN_FOR_CA
`RRIER
`
`Effect of 1ink_control=DIS-
`ABLE
`
`Effect of
`link_c0ntrol=ENABLE
`
`PMA_LINK.request(link_cont
`rol) generation
`
`PMA_LINK.request(link_cont
`rol) default upon power-on,
`reset, or release from power-
`down
`
`PMA_LINK.request(link_cont
`rol) effect of receipt
`
`28.2.6.2.3
`
`IEEE
`Std 802.3u-1995
`
`Value/comment
`
`1ink_status set to READY, OK
`or FAIL
`
`Technology-dependent PMA
`and NLP Receive Link Integ-
`rity Test state diagram (figure
`28-17) responsibility
`
`Governed by the state diagram
`of figure 28-16
`
`link_control set to
`SCAN_FOR_CARRIER, DIS-
`ABLE, or ENABLE
`
`PMA to search for carrier and
`report 1ink_status=READY
`when carrier is received, but no
`other actions are enabled
`
`Disables PMA processing
`
`Control passed to a single
`PMA for normal processing
`functions
`
`Auto-Negotiation function
`responsibility in accordance
`with figures 28-15 and 28-16
`
`link_control = DISABLE state
`to all technology-dependent
`PMAs
`
`Governed by figure 28-17 and
`the receiving technology-
`dependent link integrity test
`fimction
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0298
`
`Aerohive - Exhibit 1025
`0298
`
`

`
`IEEE
`Std 802.3u-
`
`1 995
`
`28.5.4.8
`
`State diagrams
`
`SUPPLEMENT TO 802.3:
`
`Subclause
`
`Value/comment
`
`Adherence to state diagrams
`
`Ambiguous requirements
`
`autoneg_wait_timer
`
`break_1ink_timer
`
`data_detect_min_timer
`
`data_detect_max_timer
`
`flp_test_max_timer
`
`flp_test_min_timer
`
`interVal_timer
`
`link_fail_inhibit_timer
`
`n1p_test_max_timer
`
`nlp_test_min_timer
`
`transmit_link_burst_timer
`
`28.5.4.9 Electrical characteristics
`
`Implement all features of fig-
`ures 28-14 to 28-17. Identified
`
`options to figures 28-14 to 28-
`17 are permitted
`
`State diagrams take precedence
`in defining functional
`operation
`
`Expires between 500-1000 ms
`after being started
`
`Expires between 1200-
`1500 ms after being started
`
`Expires between 15-47 its
`from the last clock pulse
`
`Expire between 78-100 us
`from the last clock pulse
`
`Expires between 165-185 its
`from the last link pulse
`
`Expires between 5-25 us from
`the last link pulse
`
`Expires 55.5-69.5 us from
`each clock pulse and data bit
`
`Expires 750-1000 ms afier
`entering the FLP LINK GOOD
`CHECK state
`
`Expires between 50-150 ms
`after being started if not
`restarted
`
`Expires between 5-7 ms after
`being started if not restarted
`
`Expires 5.7—22.3 ms after the
`last transmitted link pulse in an
`FLP Burst
`
`1
`
`ments of figure 14-12
`Pulses within FLP Bursts -
`
`Identical to the characteristics
`of NLPs and meet the require-
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`0299
`
`Aerohive - Exhibit 1025
`0299
`
`

`
`CSMA/CD
`
`28.5.4.10 Auto-Negotiation annexes
`
`IEEE
`Std 802.3u-1995
`
`Subclause
`
`Value/comment
`
`Selector Field, S[4:0] values in
`the Link Code Word
`
`Selector Field reserved
`combinations
`
`Relative priorities of the tech-
`nologies supported by the
`IEEE 802.3 Selector Field
`value
`
`Relative order of the technolo-
`gies supported by IEEE 802.3
`Selector Field
`
`Addition of new technology
`
`Addition of vendor-specific
`technology
`
`Message Code Field
`
`Message Code Field reserved
`combinations
`
`Auto-Negotiation reserved
`code 1
`
`Null Message Code
`
`Remote Fault Identifier Mes-
`sage Code
`
`Identifies base message type as
`defined by table 28-9
`
`Transmission not permitted
`
`Defined in 28B.3
`
`Remain unchanged
`
`Inserted into its appropriate
`place in the priority resolution
`hierarchy, shifting technolo-
`gies of lesser priority lower in
`priority
`
`Priority of IEEE 802.3 stan-
`dard topologies maintained,
`vendor-specific technologies to
`be inserted into an appropriate
`location
`
`Defines how following Unfor-
`matted Pages (if applicable)
`are interpreted
`
`Transmission not permitted
`
`Transmission of M10 to M0
`equals 0, not permitted
`
`Transmitted during Next Page
`exchange when the Local
`Device has no information to
`transmit and Link Partner has
`additional pages to transmit
`
`Followed by single Unformat-
`ted Page to identify fault type
`with types defined in 28C.5
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`Aerohive - Exhibit 1025
`
`0300
`
`Aerohive - Exhibit 1025
`0300
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Subclause
`
`Value/comment
`
`Organizationally Unique Iden-
`tifier Message Code
`
`PHY Identifier Message Code
`
`Auto-Negotiation reserved
`code 2
`
`Followed by 4 Unfonnatted
`Pages. First Unformatted Page
`contains most significant 11
`bits of OUI (bits 23:13) with
`MSB in U10;
`Second Unformatted Page con-
`tains next most significant 11
`bits of OUI (bits 12:2), with
`MSB in U10;
`Third Unformatted Page con-
`tains the least significant 2 bits
`of OUI (bits 1:0) with MSB in
`U10, bits U820 contains user-
`defined code specific to OUI;
`Fourth Unformatted Page con-
`tains user-defined code specific
`to OUI
`
`Followed by 4 Unformatted
`Pages. First Unformatted Page
`contains most significant 11
`bits of PHY ID (2.l5:5) with
`MSB in U10;
`Second Unfonnatted Page con-
`tains PHY ID bits 2.420 to
`3.15:l0, with MSB in U10;
`Third Unformatted Page con-
`tains PHY ID bits 3.920, with
`MSB in U10, and U0 contains
`user-defined code specific to
`PHY ID;
`Fourth Unformatted Page con-
`tains user-defined code specific
`to PHY ID
`
`Transmission of M10 to M0
`equals 1, not permitted
`
`This is anzggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exhibit 1025
`
`03 O l
`
`Aerohive - Exhibit 1025
`0301
`
`

`
`CSMA/CD
`
`28.6 Auto-Negotiation expansion
`
`IEEE
`Std 802.3u-1995
`
`Auto-Negotiation is designed in a way that allows it to be easily expanded as new technologies are devel-
`oped. When a new technology is developed, the following things must be done to allow Auto—Negotiation to
`support it:
`
`The appropriate Selector Field value to contain the new technology must be selected and allocated.
`a)
`b) A Technology bit must be allocated for the new technology within the chosen Selector Field value.
`c)
`The new technology’s relative priority within the technologies supported within a Selector Field
`value must be established.
`
`Code space allocations are enumerated in annexes 28A, 28B, and 28C. Additions and insertions to the
`armexes are allowed. No changes to existing bits already defined are allowed.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0302
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`29. System considerations for multi-segment 100BASE-T networks
`
`29.1 Overview
`
`This clause provides information on building 100BASE-T networks. The 100BASE-T technology is
`designed to be deployed in both homogenous 100 Mb/s networks and heterogeneous 10/100 Mb/s mixed
`CSMA/CD networks. Network topologies can be developed within a single 100BASE-T collision domain,
`but maximum flexibility is achieved by designing multiple collision domain networks that are joined by
`bridges and/or routers configured to provide a range of service levels to DTEs. For example, a combined
`100BASE-T/10BASE—T system built with repeaters and bridges can deliver dedicated 100 Mb/s, shared
`100 Mb/s, dedicated 10 Mb/s, and shared 10 Mb/s service to DTEs. The elfective bandwidth of shared ser-
`vices is controlled by the number of DTEs that share the service.
`
`Linking multiple 100BASE-T collision domains with bridges maximizes flexibility. Bridged topology
`designs can provide single bandwidth (figure 29-1) or multiple bandwidth (figure 29-2) services.
`
`Collision Domain 1
`
`Collision Domain 3
`
`Individual collision domains can be linked by single devices (as shown in figures 29-1 and 29-2) or by mul-
`tiple devices from any of several transmission systems. The design of multiple-collision-domain networks is
`governed by the rules defining each of the transmission systems incorporated into the design.
`
`The design of shared bandwidth 10 Mb/s collision domains is defined in clause 13; the design of shared
`bandwidth 100 Mb/s CSMA/CD collision domains is defined in the following subclauses.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0303
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Dedicated 100 Mb/s
`
`Shared 100 Mb/s
`
`100BASE—T Repeater
`
`Multi-Port
`Bridge
`
`
`
`
`
`10BASE-T Repeater
`
`
`
`Dedicated 10 Mb/s
`
`Shared 10 Mb/s
`
`29.1.1 Single collision domain multi-segment networks
`
`This clause provides information on building 100 Mb/s CSMA/CD multi-segment networks within a single
`collision domain. The proper operation of a CSMA/CD network requires the physical size and number of
`repeaters to be limited in order to meet the round—trip propagation delay requirements of 4.2.3.2.3 and
`4.4.2.1 and IPG requirements specified in 4.4.2.1.
`
`This clause provides two network models. Transmission System Model 1 is a set of configurations that have
`been validated under conservative rules and have been qualified as meeting the requirements set forth above.
`Transmission System Model 2 is a set of calculation aids that allow those configuring a network to test a pro-
`posed configuration against a simple set of criteria that allows it to be qualified. Transmission System Model
`2 validates an additional broad set of topologies that are fully functional and do not fit within the simpler, but
`more restrictive rules of Model 1.
`
`The physical size of a CSMA/CD network is limited by the characteristics of individual network compo-
`nents. These characteristics include the following:
`
`a) Media lengths and their associated propagation time delay
`b) Delay of repeater units (start-up, steady-state, and end of event)
`c)
`Delay of MAUs and PHYS (start-up, steady-state, and end of event)
`d)
`Interpacket gap shrinkage due to repeater units
`e) Delays within the DTE associated with the CSMA/CD access method
`f)
`Collision detect and deassertion times associated with the MAUs and PHYS
`
`Table 29-1 summarizes the delays for 100BASE—T media segments. For more detailed information on the
`delays associated with individual 100BASE—T components, see
`
`MII:
`100BASE-T4:
`100BASE-TX:
`100BASE-FX:
`
`armex 22A
`23.11
`armex 24A
`armex 24A
`
`This is anzggrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0304
`
`

`
`CSMNCD
`
`Repeater:
`
`27.3
`
`IEEE
`Std 802.3u-1995
`
`Table 29-1—Delays for network media segments Model 1
`
`
`
`29.1.2 Repeater usage
`
`Repeaters are the means used to connect segments of a network medium together into a single collision
`domain. Diiferent physical signaling systems (e.g., l00BASE-T4, l00BASE-TX, IOOBASE-FX) can be joined
`into a common collision domain using repeaters. Bridges can also be used to connect dilferent signaling sys-
`tems; however, if a bridge is so used, each system connected to the bridge will be a separate collision domain.
`
`Two types of repeaters are defined for l00BASE-T (see clause 27). Class I repeaters are principally used to
`connect unlike physical signaling systems and have internal delays such that only one Class I repeater can
`reside within a single collision domain when maximum cable lengths are used (see figure 29-4). Class II
`repeaters typically provide ports for only one physical signaling system type (e.g., IOOBASE-TX but not
`IOOBASE-T4) and have smaller internal delays so that two such repeaters may reside within a given colli-
`sion domain when maximum cable lengths are used (see figure 29-6). Cable length can be sacrificed to add
`additional repeaters in a collision domain (sec 29.3).
`
`29.2 Transmission System Model 1
`
`The following network topology constraints apply to networks using Transmission System Model 1.
`
`a) All balanced cable (copper) segments less than or equal to 100 in each.
`h)
`Fiber segments less than or equal to 412 m each.
`c) M11 cables for l00BASE-T shall not exceed 0.5 111 each. When evaluating system topology, MII
`cable delays need not be accounted for separately. Delays attributable to the MII are incorporated
`into DTE and repeater component delays.
`
`29.3 Transmission System Model 2
`
`The physical size and number of topological elements in a l00BASE-T network is limited primarily by
`round-trip collision delay. A network configuration must be validated against collision delay using a network
`model. Since there are a limited number of topology models for any l00BASE-T collision domain, the mod-
`eling process is quite straightforward and can easily be done either manually or with a spreadsheet.
`
`The model proposed here is derived from the one presented in 13.4. Modifications have been made to
`accommodate adjustments for DTE, repeater, and cable speeds.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0305
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`<
`See table 29-2 for maximum segment length.
`
`
`
`Repeater Set
`
`A+B = collision domain diameter
`
`
`
`>
`4
`See table 29-2 for maximum collision domain diameter.
`
`A+B+C= collision domain diameter
`
`Repeater Set
`
`<
`
`See table 29-2 for maximum collision domain diameter.
`
`This is anzgllrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0306
`
`

`
`CSMA/CD
`
`IEEE
`Std 8D2.3u-1995
`
`Table 29-2—Maximum Model 1 collision domain diameter“
`
`
`
`“In meters, no margin.
`bAssumes 100 m of balanced cable and one fiber link.
`‘This entry included for completeness. It may be impractical to construct a T4 to FX class H repeater.
`dAssumes 105 m of balanced cable and one fiber link.
`
`29.3.1 Round-trip collision delay
`
`For a network to be valid, it must be possible for any two DTEs on the network to contend for the network at
`the same time. Each station attempting to transmit must be notified of the contention by the returned “colli-
`sion” signal within the “collision window” (see 4.1.2.2 and 5.2.2.1.2). Additionally, the maximum length
`fragment created must contain less than 512 bits after the start-of-frame delimiter (SFD). These require-
`ments lirnit the physical diameter (maximum distance between DTEs) of a network. The maximum round-
`trip delay must be qualified between all pairs of DTEs in the network. In practice this means that the qualifi-
`cation must be done between those that, by inspection of the topology, are candidates for the longest delay.
`The following network modeling methodology is provided to assist that calculation.
`
`29.3.1.1 Worst-case path delay value (PDV) selection
`
`The worst-case path through a network to be validated shall be identified by examination of aggregate DTE
`delays, cable delays, and repeater delays. The worst case consists of the path between the two DTEs at oppo-
`site ends of the network that have the longest round-trip time. Figures 29-6 and 29-7 show schematic repre-
`sentatins of one-repeater and two-repeater paths.
`
`REPE ATER =
`
`Media cable
`
`29.3.1.2 Worst-case PDV calculation
`
`Once a set of paths is chosen for calculation, each shall be checked for validity against the following formula:
`
`PDV = Elink delays (LSDW + Xrepeater delays + DTE delays + safety margin
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0307
`
`

`
`IEEE
`Std 302.3u-1995
`
`SUPPLEMENT TO 302.3:
`
`End
`
`Inter-
`Repeater
`Link
`
`REPEA TER
`
`= MII cable
`JUITI-|>|T|'U|'|'|;U
`
`= Media cable
`
`Values for the formula variables are determined by the following method:
`
`a)
`
`Determine the delay for each link segment (Link Segment Delay Value, or LSDV), including inter-
`repeater links, using the formula
`
`LSDV=2 (for round-trip delay) x segment length X cable delay for this segment
`
`NOTES
`
`l—Length is the sum of the cable lengths between the PHY interfaces at the repeater and the farthest DTE for
`End Segments plus the sum of the cable lengths between the repeater PHY interfaces for Inter-Repeater Links.
`All measurements are in meters.
`
`2—Cable delay is the delay specified by the manufacturer or the maximum value for the type of cable used as
`shown in table 29-3. For this calculation, cable delay must be specified in hit times per meter (BT/m). Table 29-
`4 can be used to convert values specified relative to the speed of light (%c) or nanoseconds per meter (ns/m).
`3—When actual cable lengths or propagation delays are not lmown, use the Max delay in hit times as specified
`in table 29-3 for copper cables. Delays for fiber should be calculated, as the value found in table 29-3 will be
`too large for most applications.
`
`Sum together the LSDVs for all segments in the path.
`Determine the delay for each repeater in the path. If model-specific data are not available from the
`manufacturer, determine the class of each repeater (I or II) and enter the appropriate default value
`from table 29-3.
`
`MII cables for IOOBASE-T shall not exceed 0.5 In each. When evaluating system topology, M11
`cable delays need not be accounted for separately. Delays attributable to the MII are incorporated
`into DTE and repeater component delays.
`Use the DTE delay value shown in table 29-3 unless your equipment manufacturer defines a differ-
`ent value.
`
`Decide on appropriate safety margin—0 to 5 bit times—for the PDV calculation. Safety margin is
`used to provide additional margin to accommodate unanticipated delay elements, such as extra-long
`connecting cable runs between wall jacks and DTEs. (A safety margin of 4 BT is recommended.)
`Insert the values obtained through the calculations above into the following formula to calculate the
`PDV. (Some configurations may not use all the elements of the formula.)
`
`PDV = Elink delays (LSDV) + Erepeater delays + DTE delay + safety margin
`
`If the PDV is less than 512, the path is qualified in terms of worst-case delay.
`Late collisions and/or CRC errors are indicators that path delays exceed 512 BT.
`
`g)
`
`h)
`
`This is anzggchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
` bit 1025
`0308
`
`Aerohive - Exhibit 1025
`0308
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`Table 29-3—Network component delays, Transmission System Model 2
`
`Round-trip delay in bit
`times per meter
`
`Maximum round-trip
`delay in bit times
`100
`138
`127
`
`Component
`
`Two TX/FX DTEs
`Two T4 DTEs
`One T4 and one TX/FX
`DTEa
`
`Cat 3 cable segment
`Cat 4 cable segment
`Cat 5 cable segment
`STP cable segment
`Fiber optic cable segment
`Class I repeater
`Class II repeater with all
`ports TX/FX
`Class II repeater with any
`
`port T4
`
`.
`
`.
`
`114 (100 m)
`114 (100 m)
`111.2 (100 m)
`111.2 (100 m)
`412 (412 In)
`140
`92
`
`67
`
`“Worst-case values are used (TX/FX values for MAC transmit start and MDI input to colli-
`sion detect; T4 value for MDI input to MDI output).
`
`Table 29-4—Conversion table for cable delays
`
`Speed relative to c
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`Aerohive - Exhibit 1025
`
`0309
`
`Aerohive - Exhibit 1025
`0309
`
`

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

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`30. Layer Management for 10 Mbls and 100 Mbls
`
`30.1 Overview
`
`This clause provides the Layer Management specification for DTEs, repeaters, and MAUs based on the
`CSMA/CD access method. The clause is produced from the ISO framework additions to clause 5, Layer
`Management; clause 19, Repeater Management; and clause 20, MAU Management. It incorporates additions
`to the objects, attributes, and behaviors to support 100 Mb/s CSMA/CD.
`
`The layout of this clause takes the same form as 5.1, 5.2, and clauses 19 and 20, although with equivalent
`subclauses grouped together. It identifies a common management model and framework applicable to IEEE
`802.3 managed elements, and it identifies those elements and defines their managed objects, attributes, and
`behaviors ill a protocol-independent language. It also includes a formal GDMO definition of the protocol
`encodings for CMIP and ISO/IEC 15802-2: 1995 [IEEE 802.lB].
`
`NOTE—The arcs (that is, object identifier values) defined in annex 30A, the formal GDMO definitions, deprecate the
`arcs previously defined in Annexes D1 (Layer Management), D2 (Repeater Management), and D3 (MAU Management).
`See IEEE Std 802.lF-1993, annex C.4.
`
`This clause provides the Layer Management specification for DTEs, repeaters, and MAUs based on the
`CSMA/CD access method. It defines facilities comprised of a set of statistics and actions needed to provide
`IEEE 802.3 Management services. The information in this clause should be used in conjunction with the
`Procedural Model defined in 4.2.7—4.2.10. The Procedural Model provides a formal description of the rela-
`tionship between the CSMA/CD Layer Entities and the Layer Management facilities.
`
`This management specification has been developed in accordance with the OSI management architecture as
`specified in the ISO Management Framework document, ISO/IEC 7498-4: 1989. It is independent of any
`particular management application or management protocol.
`
`The management facilities defined in this standard may be accessed both locally and remotely. Thus, the
`Layer Management specification provides facilities that can be accessed from within a station or can be
`accessed remotely by means of a peer-management protocol operating between application entities.
`
`In CSMA/CD no peer management facilities are necessary for initiating or terminating normal protocol
`operations or for handling abnormal protocol conditions. The monitoring of these activities is done by the
`carrier sense and collision detection mechanisms. Since these activities are necessary for normal operation
`of the protocol, they are not considered to be a function of Layer Management and are, therefore, not dis-
`cussed in this clause.
`
`Implementation of part or all of 10 Mb/s and 100 Mb/s Management is not a requirement for conformance to
`clauses 4, 7, 9, 22, 23, 24, 25, 26, 27, or 28.
`
`The intent of this standard is to furnish a management specification that can be used by the wide variety of
`different devices that may be attached to a network specified by ISO/IEC 8802-3. Thus, a comprehensive list
`of management facilities is provided.
`
`The improper use of some of the facilities described in this clause may cause serious disruption of the net-
`work. In accordance with ISO management architecture, any necessary security provisions should be pro-
`vided by the Agent in the Local System Environment. This can be in the form of specific security features or
`in the form of security features provided by the peer communication facilities.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0311
`
`

`
`IEEE
`Std 802.3u-1995
`
`30.1.1 Scope
`
`SUPPLEMENT TO 802.3:
`
`This clause includes selections fiom clauses 5, 19, and 20. It is intended to be an entirely equivalent specifi-
`cation for the management of 10 Mb/s DTEs, 10 Mb/s baseband repeater units, and 10 Mb/s integrated
`MAUs. It also includes the additions for management of 100 Mb/s DTEs, repeater units, embedded MAUs,
`and external PHYs connected with the MII. Implementations of management for 10 Mb/s DTEs, repeater
`units, and embedded MAUs should follow the requirements of this clause (e.g., a 10 Mb/s implementation
`should incorporate the attributes to indicate that it is not capable of 100 Mb/s operation).
`
`This clause defines a set of mechanisms that enable management of ISO/IEC 8802-3 10 Mb/s and 100 Mb/s
`DTEs, baseband repeater units, and integrated Medium Attachment Units (MAUs). In addition, for ports
`without integral MAUs, attributes are provided for characteristics observable from the AUI of the connected
`DTE or repeater. Direct management ofAUI MAUs that are external to their respective DTEs or repeaters is
`beyond the scope of this standard. The managed objects within this standard are defined in terms of their
`behaviour, attributes, actions, notifications, and packages in accordance with IEEE 802.1 and ISO standards
`for network management. Managed objects are grouped ir1to mandatory and optional packages.
`
`This specification is defined to be independent of any particular management application or management
`protocol. The means by which the managed objects defined in this standard are accessed is beyond the scope
`of this standard.
`
`30.1.2 Relationship to objects in IEEE Std 802.1F-1993
`
`The following managed object classes, if supported by an implementation, shall be as specified in IEEE Std
`802.lF-1993: ResourceType]D, EWMAMe11icMonitor.
`
`oResourceTypeID
`
`oEWMAMetricMonitor
`
`This object class is mandatory and shall be implemented as defined in
`IEEE Std 802. 1F-1993. This object is bound to oMAC-Entity,
`oRepeater, and oMAU as defined by the NAMEBINDINGS in 30A.8. 1 .
`Note that the binding to oMAU is mandatory only when MII is present.
`The Entity Relationship Diagram, figure 30-3, shows these bindings
`pictorially.
`
`This object class is optional. When implemented, it shall be implemented
`as defined in IEEE Std 802.1F-1993, subject to the specific requirements
`described below. This object is bound to system as defined by the
`NAMEBINDINGS in 30A.1.1, 30A.3.l, and 30A.2.l.
`
`Implementations of IEEE 802.3 Management that support the oEWMAMetricMonitor managed object class
`are required to support values of granularity period as small as one second. Implementations are required to
`support at least one sequence of low and high thresholds. The granularity period may be set to equal to the
`moving time period as a minimal conformant implementation.
`
`30.1.3 Systems management overview
`
`Within the ISO Open Systems Interconnection (OSI) architecture, the need to handle the special problems of
`initializing, terminating, and monitoring ongoing activities and assisting in their operations, as well as han-
`dling abnormal conditions, is recognized. These needs are collectively addressed by the systems manage-
`ment component of the OSI architecture.
`
`A management protocol is required for the exchange of information between systems on a network. This
`management standard is independent of any particular management protocol.
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0312
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`This management standard, in conjunction with the management standards of other layers, provides the
`means to perform various management fLmctions. IEEE 802.3 Management collects information needed
`from the MAC and Physical Layers and the devices defined in IEEE 802.3. It also provides a means to exer-
`cise control over those elements.
`
`The relationship between the various management entities and the layer entities according to the ISO model
`is shown in figure 30-1.
`
`30.1.4 Management model
`
`This standard describes management of DTEs, repeaters, and integrated MAUs in terms of a general model
`of management of resources within the open systems environment. The model, which is described in ISO/
`[EC 10040: 1992, is briefly summarized here.
`
`Management is viewed as a distributed application modeled as a set of interacting management processes.
`These processes are executed by systems within the open environment. A managing system executes a man-
`aging process that invokes management operations. A managed system executes a process that is receptive to
`these management operations and provides an interface to the resources to be managed. A managed object is
`the abstraction of a resource that represents its properties as seen by (and for the purpose of) management.
`Managed objects respond to a defined set of management operations. Managed objects are also capable of
`emitting a defined set of notifications. This interaction of processes is shown in figure 30-1.
`
`Communicating
`Management Operations
`am’
`
`Notifications
`
`A managed object is a management view of a resource. The resource may be a logical construct, function,
`physical device, or anything subject to management. Managed objects are defined in terms of four types of
`elements:
`
`a) Attributes. Data-like properties (as seen by management) of a managed object.
`b) Actions. Operations that a managing process may perform on an object or its attributes.
`c)
`Notifications. Unsolicited reports of events that may be generated by an object.
`d)
`Behaviour: The way in which managed objects, attributes, and actions interact with the actual
`resou