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.
`
`305
`
`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.
`
`0306
`
`it 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.
`
`307
`
`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.
`
`
`
`it 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.
`
`1025
`
`0310
`
`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.
`
`it 1025
`
`0311
`
`
`
`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.
`
`0312
`
`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
`resources they model and with each other.
`
`The above items are defined in 30.3, 30.4, 30.5, and 30.6 of this clause in terms of the template requirements
`of ISO/IEC 10165-4: 1991.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggqrd.
`
`0313
`
`'t 1025
`
`Aerohive - Exhibit 1025
`0313
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Some of the functions and resources within 802.3 devices are appropriate targets for management. They
`have been identified by specifying managed objects that provide a management view of the functions or
`resources. Within this general model, the 802.3 device is viewed as a managed device. It performs fimctions
`as defined by the applicable standard for such a device. Managed objects providing a view of those functions
`and resources appropriate to the management of the device are specified. The purpose of this standard is to
`define the object classes associated with the devices in terms of their attributes, operations, notifications, and
`behaviour.
`
`30.2 Managed objects
`
`30.2.1 Introduction
`
`This clause identifies the Managed Object classes for IEEE 802.3 components within a managed system. It
`also identifies which managed objects and packages are applicable to which components.
`
`All counters defined in this specification are assumed to be wraparound counters. Wraparound counters are
`those that automatically go from their maximum Value (or final value) to zero and continue to operate. These
`unsigned counters do not provide for any explicit means to return them to their minimum (zero), i.e., reset.
`Because of their nature, wraparound counters should be read frequently enough to avoid loss of information.
`Counters in 30.3, 30.4, 30.5 and 30.6 that have maximum increment rates specified for 10 Mb/s operation,
`and are appropriate to 100 Mb/s operation, have ten times the stated maximum increment rate for 100 Mb/s
`operation unless otherwise indicated.
`
`30.2.2 Overview of managed objects
`
`Managed objects provide a means to
`
`— Identify a resource
`— Control a resource
`— Monitor a resource
`
`30.2.2.1 Text description of managed objects
`
`In case of conflict, the formal behaviour definitions in 30.3, 30.4, 30.5, and 30.6 take precedence over the
`text descriptions in this subclause.
`
`oMACEntity
`
`oPHYEntity
`
`oRepeater
`
`The top-most managed object class of the DTE portion of the
`containment tree shown in figure 30-3. Note that this managed object
`class may be contained within another superior managed object class.
`Such containment is expected, but is outside the scope of this standard.
`
`Contained within oMACEntity. Many instances of oPHYEntity may
`coexist within one instance of oMACEntity; however, only one PHY
`may be active for data transfer to and from the MAC at any one time.
`oPHYEntity is the managed object that contains the MAU managed
`object in a DTE.
`
`The top-most managed object class of the repeater portion of the
`containment tree shown in figure 30-3. Note that this managed object
`class may be contained within another superior managed object class.
`Such containment is expected, but is outside the scope of this standard.
`
`This is anzsgrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`314
`
`1025
`
`Aerohive - Exhibit 1025
`0314
`
`

`
`CSMNCD
`
`IEEE
`Std 802.3u-1995
`
`oRepeaterMonitor
`
`oGroup
`
`oRepeaterPort
`
`oMAU
`
`oAutoNegotiation
`
`oResourceTypeID
`
`A managed object class called out by IEEE Std 802.lF-1993. See 30.1.2,
`oEWMAMetricMonitor.
`
`The group managed object class is a View of a collection ofrepeater ports.
`
`The repeater port managed object class provides a view of the fimctional
`link between the data transfer service and a single PMA. The attributes
`associated with repeater port deal with the monitoring of traffic being
`handled by the repeater fi'om the port and control of the operation of the
`port. The Port Enable/Disable fimction as reported by portAdminState is
`preserved across events involving loss of power. The oRepeaterPort
`managed object contains the MAU managed object in a repeater set.
`
`NOTE—Attachment to nonstandard PMAs is outside the scope of this standard.
`
`The managed object of that portion of the containment tree shown in
`figure 30-3. The attributes, notifications, and actions defined in this
`clause are contained within the MAU managed object. Neither counter
`values nor the value of MAUAdminState is required to be preserved
`across events involving the loss of power.
`
`The managed object of that portion of the containment tree shown in
`figure 30-3. The attributes, notifications, and actions defined in this
`clause are contained within the MAU managed object.
`
`A managed object class called out by IEEE Std 802.1F-1993. It is used
`within this clause to identify manufacturer, product, and revision of
`managed components that implement functions and interfaces defined
`within IEEE 802.3. The clause 22 lVlII specifies two registers to carry
`PHY Identifier (22.2.4.3.1), which provides succinct information
`sufficient to support oResourceTypeID.
`
`30.2.2.2 Functions to support management
`
`Functions are defined in clauses 5, 7, 22, 23, 24, 25, 26, 27, and 28 both to facilitate unmanaged operation
`and managed operation. The functions in these clauses that facilitate managed operation are referenced from
`the text of this management clause.
`
`30.2.2.2.1 DTE MAC sublayer functions
`
`For DTE MACs, with regard to reception-related error statistics a hierarchical order has been established
`such that when multiple error statuses can be associated with one frame, only one status is returned to the
`LLC. This hierarchy in descending order is as follows:
`
`— frameTooLong
`— alignmentError
`— frameCheckError
`
`— lengthError
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggajd.
`
`
`
`Aerohive - Exhibit 1025
`0315
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`The counters are primarily incremented based on the status returned to the LLC; therefore, the hierarchical
`order of the counters is determined by the order of the status. Frame fragments are not included in any of the
`statistics unless otherwise stated. In implementing any of the specified actions, receptions and transmissions
`that are in progress are completed before the action takes effect.
`
`30.2.2.2.2 Repeater functions
`
`The Repeater Port Object class contains seven functions which are defined in this clause and are used to col-
`lect statistics on the activity received by the port. The relationship of the fimctions to the repeater port and to
`the port attributes is shown in figure 30-2.
`
`Activity Timing function
`
`Carrier Event function
`
`Collision Event function
`
`The Activity Timing function measures the duration of the assertion of
`the CarrierEvent signal. This duration value must be adjusted by
`removing the value of Carrier Recovery Time (see 9.5.6.5) to obtain the
`true duration of activity on the network. The output of the Activity
`Timing function is the ActivityDuration value, which represents the
`duration of the CarrierEvent signal as expressed in units of bit times.
`
`The Carrier Event fimction asserts the CarrierEvent signal when the
`repeater exits the IDLE state (see figure 9-2) and the port has been
`determined to be port N. It de-asserts the CarrierEvent signal when, for
`a duration of at least Carrier Recovery Time (see 9.5.6.5), both the
`DataIn(N) variable has the value II and the CollIn(N) variable has the
`value —SQE. The value N is the port assigned at the time of transition
`fi'om the ]DLE state.
`
`The Collision Event fimction asserts the CollisionEvent signal when the
`CollIn(X) variable has the value SQE. The CollisionEvent signal
`remains asserted until the assertion of any CarrierEvent signal due to the
`reception of the following event.
`
`Cyclic Redundancy Check function
`The Cyclic Redundancy Check function verifies that the sequence of
`octets output by the Framing fimction contains a Valid Frame Check
`Sequence Field. The Frame Check Sequence Field is the last four octets
`received from the output of the Framing function. The algorithm for
`generating an FCS from the octet stream is specified in 3.2.8. If the FCS
`generated according to this algorithm is not the same as the last four
`octets received from the Framing function, then the FCSError signal is
`asserted. The FCSError signal is cleared upon the assertion of the
`CarrierEvent signal due to the reception of the following event.
`
`Framing function
`
`The Framing function recognizes the boundaries of an incoming frame
`by monitoring the CarrierEvent signal and the decoded data stream. Data
`bits are accepted while the CarrierEvent signal is asserted. The framing
`fimction strips preamble and start-of-frame delimiter fi'om the received
`data stream. The remaining bits are aligned along octet boundaries. If
`there is not an integral number of octets, then FramingError shall be
`asserted. The FramingError signal is cleared upon the assertion of the
`CarrierEvent signal due to the reception of the following event.
`
`This is anzétrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`
`
`1025
`
`316
`
`Aerohive - Exhibit 1025
`0316
`
`

`
`CSMA/CD
`
`Octet Counting function
`
`Source Address function
`
`IEEE
`Std 802.3u-1995
`
`The Octet Counting fLlI1Cti01'1 counts the number of complete octets
`received from the output of the framing fimction. The output ofthe octet
`counting function is the OctetCount value. The OctetCountva1ue is reset
`to zero upon the assertion ofthe Ca1rierEvent signal due to the reception
`of the following event.
`
`The Source Address function extracts octets from the stream output by
`the framing function. The seventh through twelfth octets shall be
`extracted from the octet stream and output as the SourceAddress
`variable. The SourceAddress variable is set to an invalid state upon the
`assertion of the Ca1rierEvent signal due to the reception ofthe following
`event.
`
`REPEATER PORT OBJECT
`
`Co||isionEvent
`
`Datamx)
`
`‘
`
`decodedData
`
`ActivityDuration
`
`
`CarrierEvent
`FramingError
`
`OctetCount
`
`FCSError
`
`SourceAddress
`
`30.2.3 Containment
`
`A containment relationship is a structuring relationship for managed objects in which the existence of a
`managed object is dependent on the existence of a containing managed object. The contained managed
`object is said to be the subordinate managed object, and the containing managed object the superior man-
`aged object. The containment relationship is used for naming managed objects. The local containment rela-
`tionships among object classes are depicted in the entity relationship diagram, figure 30-3. This figure also
`shows the names, naming attributes, and data attributes of the object classes as well as whether a particular
`containment relationship is one-to-one or one-to-many. For further requirements on this topic, see IEEE Std
`802.1F—l993.
`
`MAU management is only valid in a system that provides management at the next higher containment level,
`that is, either a DTE or repeater with management.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this stanggrd.
`
`
`
`1025
`
`317
`
`Aerohive - Exhibit 1025
`0317
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`oResourceType|D
`
`I'_I5:5_-°»'<z?=_t'i_f'_ii_II‘.
`
`Repeater System
`
`DTE System
`
`—» Denotes one-to-many relationship
`Tb Denotes one-to-one relationship
`
`30.2.4 Naming
`
`The name of an individual managed object is hierarchically defined within a managed system. For example,
`in the context of repeater management, a repeater port might be identified as “repeater 3, group 01, port 13,”
`that is, port 13 of group 01 of a repeater with repeaterID 3 within the managed system.
`
`In the case of MAU management, this will present itself in one of the two forms that are appropriate for a
`MAU’s use, that is, as associated with a CSMA/CD interface of a DTE or with a particular port of a managed
`repeater. For example, a MAU could be identified as “repeater 3, group 01, port 13, MAU 1” or, that is, the
`MAU associated with port 13 of group 01 of a repeater with repeaterID 3 within the managed system. Exam-
`ples of this are represented in the relationship of the naming attributes in the entity relationship diagram, fig-
`ure 30-3.
`
`30.2.5 Capabilities
`
`This standard makes use of the concept of packages as defined in ISO/IEC 10165-4: 1992 as a means of
`grouping behaviour, attributes, actions, and notifications within a managed object class definition. Packages
`may either be mandatory or conditional, that is to say, present if a given condition is true. Within this stan-
`dard, capabilities are defined, each of which corresponds to a set of packages, which are components of a
`number of managed object class definitions and which share the same condition for presence. Implementa-
`tion of the appropriate basic and the mandatory packages is the minimum requirement for claiming conform-
`
`This is anzegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`318
`
`1025
`
`Aerohive - Exhibit 1025
`0318
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`ance to IEEE 802.3 10 Mb/s and 100 Mb/s Management. Implementation of an entire optional capability is
`required in order to claim conformance to that capability. The capabilities and packages for 10 Mb/s and
`100 Mb/s Management are specified in table 30-1 (broken into tables 30-la through 30-1d for pagination).
`
`DTE Management has two packages that are required for management at the minimum conformance config-
`uration—the Basic Package and the Mandatory Package. For systems that include multiple PHY entities per
`MAC entity, and implement the Multiple PHY Package to manage the selection of the active PHY, the
`optional Recommended Package shall be implemented.
`
`For managed MAUs, the Basic Package is mandatory; all other packages are optional. For a managed MAU
`to be conforrnant to this standard, it shall fully implement the Basic Package. For a MAU to be conforrnant
`to an optional package, it shall implement that entire package. While nonconformant (reference aMAUType
`“other”) MAUs may utilize some or all of this clause to specify their management, conformance to this
`clause requires both a conformant MAU and conforrnant management. MAU Management is optional with
`respect to all other CSMA/CD Management. If an M11 is present, then the conditional MII Capability must
`be implemented. This provides the means to identify the vendor and type of the externally connected device.
`
`There are two distinct aspects of Repeater Management.
`
`The first aspect provides the means to monitor and control the functions of a repeater. These functions
`include, but are not limited to identifying a repeater, testing and initializing a