IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Feature
`
`Subclause
`
`Status
`
`Support
`
`Value/comment
`
`Followed by 4 Unformatted
`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 U8:0 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.15:5) with
`MSB in U10;
`Second Unformatted Page con-
`tains PHY ID bits 2.4:0 to
`3.15:10, with MSB in U10;
`Third Unformatted Page con-
`tains PHY ID bits 3.9:0, 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
`
`Item
`
`12
`
`Organizationally Unique Iden-
`tifier Message Code
`
`28C.6
`
`NP:M
`
`13
`
`PHY Identifier Message Code
`
`28C.7
`
`NP:M
`
`14
`
`Auto-Negotiation reserved
`code 2
`
`28C.8
`
`NP:M
`
`280
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 301
`
` Dell Inc.
` Exhibit 1009 (Part 4 of 5)
`
`

`
`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
`annexes are allowed. No changes to existing bits already defined are allowed.
`
`281
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 302
`
`

`
`
`
`
`
`
`
`
`CSMA/CD
`
`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 effective 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 4
`
`DTE
`
`DTE
`
`Repeater
`
`DTE
`
`DTE
`
`Collision Domain 1
`
`DTE
`
`DTE
`
`DTE
`
`DTE
`
`Repeater
`
`Multi-Port
`Bridge
`
`Repeater
`
`DTE
`
`DTE
`
`DTE
`
`DTE
`
`Collision Domain 3
`
`Collision Domain 2
`
`DTE
`
`DTE
`
`Repeater
`
`DTE
`
`DTE
`
`Figure 29-1—100 Mb/s multiple collision domain topology using multi-port bridge
`
`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.
`
`281
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 303
`
`

`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Dedicated 100 Mb/s
`
`Shared 100 Mb/s
`
`DTE 1
`
`DTE 2
`
`DTE 3
`
`DTE 4
`
`DTE 5
`
`100 Mb/s
`
`100 Mb/s
`
`100BASE-T Repeater
`
`100 Mb/s
`
`Multi-Port
`Bridge
`
`10 Mb/s
`
`10 Mb/s
`
`10 Mb/s
`
`10BASE-T Repeater
`
`DTE 6
`
`DTE 7
`
`DTE 8
`
`DTE 9
`
`DTE 10
`
`Dedicated 10 Mb/s
`
`Shared 10 Mb/s
`
`Figure 29-2—Multiple bandwidth, multiple collision domain topology using
`multi-port bridge
`
`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:
`
`annex 22A
`23.11
`annex 24A
`annex 24A
`
`282
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 304
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`Repeater:
`
`27.3
`
`IEEE
`Std 802.3u-1995
`
`Table 29-1—Delays for network media segments Model 1
`
`Media type
`
`Balanced cable Link Segment 100BASE-T
`
`Fiber Link Segment
`
`29.1.2 Repeater usage
`
`Maximum
`number of
`PHYs per
`segment
`
`2
`
`2
`
`Maximum
`segment
`length (m)
`
`Maximum medium
`round-trip delay per
`segment (BT)
`
`100
`
`412
`
`114
`
`412
`
`Repeaters are the means used to connect segments of a network medium together into a single collision
`domain. Different physical signaling systems (e.g., 100BASE-T4, 100BASE-TX, 100BASE-FX) can be joined
`into a common collision domain using repeaters. Bridges can also be used to connect different 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 100BASE-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., 100BASE-TX but not
`100BASE-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 (see 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 m each.
`b)
`Fiber segments less than or equal to 412 m each.
`c) MII cables for 100BASE-T shall not exceed 0.5 m 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 100BASE-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 100BASE-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.
`
`283
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 305
`
`

`
`
`
`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`DTE w/MII
`
`DTE w/MII
`
`See table 29-2 for maximum segment length.
`
`Figure 29-3—Model 1: Two DTEs, no repeater
`
`Repeater Set
`
`A
`
`B
`
`DTE
`
`DTE
`
`A+B = collision domain diameter
`
`See table 29-2 for maximum collision domain diameter.
`
`Figure 29-4—Model 1: Single repeater
`
`Repeater Set
`
`B
`
`Repeater Set
`
`A
`
`C
`
`DTE
`DTE
`A+B+C= collision domain diameter
`
`See table 29-2 for maximum collision domain diameter.
`
`Figure 29-5—System Model 1: Two Class II repeaters
`
`284
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 306
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`a
`Table 29-2—Maximum Model 1 collision domain diameter
`
`
`Model
`
`DTE-DTE (see figure 29-3)
`
`One Class I repeater (see figure 29-4)
`
`One Class II repeater (see figure 29-4)
`
`Two Class II repeaters (see figure 29-5)
`
`Balance
`d cable
`(copper)
`
`100
`
`200
`
`200
`
`205
`
`Fiber
`
`Balanced cable & fiber
`(T4 and FX)
`
`Balanced cable & fiber
`(TX and FX)
`
`412
`
`272
`
`320
`
`228
`
`na
`
`b
`
`231
`
`b,c
`
`304
`
`d,c
`236.3
`
`na
`
`260.8
`
`308.8
`
`216.2
`
`b
`
`b
`
`d
`
`a
`In meters, no margin.
`b
`Assumes 100 m of balanced cable and one fiber link.
`c
`This entry included for completeness. It may be impractical to construct a T4 to FX class II repeater.
`d
`Assumes 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 limit 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.
`
`PHY
`
`PHY
`
`DTE
`
`R E P E A T E R
`
`DTE
`
`PHY
`
`PHY
`
`= MII cable
`
`= Media cable
`
`Figure 29-6—System Model 2: Single repeater
`
`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 =
`
`link delays (LSDV) +
`
`repeater delays + DTE delays + safety margin
`
`285
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 307
`
`(cid:229)
`(cid:229)
`

`
`SUPPLEMENT TO 802.3:
`
`End
`Segment
`
`PHY
`
`PHY
`
`DTE
`
`R E P E A T E R
`
`Inter-
`Repeater
`Link
`
`PHY
`
`PHY
`
`R E P E A T E R
`
`IEEE
`Std 802.3u-1995
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`End
`Segment
`
`DTE
`
`PHY
`
`PHY
`
`= MII cable
`
`= Media cable
`
`Figure 29-7—System Model 2-2: Two repeaters
`
`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)
`
` segment length
`
` cable delay for this segment
`
`NOTES
`1—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 bit 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 known, use the Max delay in bit 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.
`b)
`c) 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.
`d) MII cables for 100BASE-T shall not exceed 0.5 m 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.
`e) 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.)
`
`g)
`
`f)
`
`PDV =
`
`link delays (LSDV) +
`
`repeater delays + DTE delay + safety margin
`
`h)
`i)
`
`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.
`
`286
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 308
`
`·
`·
`(cid:229)
`(cid:229)
`

`
`CSMA/CD
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`Table 29-3—Network component delays, Transmission System Model 2
`
`Component
`
`Round-trip delay in bit
`times per meter
`
`Two TX/FX DTEs
`Two T4 DTEs
`One T4 and one TX/FX
`a
`DTE
`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
`
`1.14
`1.14
`1.112
`1.112
`1.0
`
`Maximum round-trip
`delay in bit times
`100
`138
`127
`
`114 (100 m)
`114 (100 m)
`111.2 (100 m)
`111.2 (100 m)
`412 (412 m)
`140
`92
`
`67
`
`a
`
`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
`0.4
`0.5
`0.51
`0.52
`0.53
`0.54
`0.55
`0.56
`0.57
`0.58
`0.5852
`0.59
`0.6
`0.61
`0.62
`0.63
`0.64
`0.65
`0.654
`0.66
`0.666
`0.67
`0.68
`0.69
`0.7
`0.8
`0.9
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ns/m
`8.34
`6.67
`6.54
`6.41
`6.29
`6.18
`6.06
`5.96
`5.85
`5.75
`5.70
`5.65
`5.56
`5.47
`5.38
`5.29
`5.21
`5.13
`5.10
`5.05
`5.01
`4.98
`4.91
`4.83
`4.77
`4.17
`3.71
`
`BT/m
` 0.834
` 0.667
` 0.654
` 0.641
` 0.629
` 0.618
` 0.606
` 0.596
` 0.585
` 0.575
` 0.570
` 0.565
` 0.556
` 0.547
` 0.538
` 0.529
` 0.521
` 0.513
` 0.510
` 0.505
` 0.501
` 0.498
` 0.491
` 0.483
` 0.477
` 0.417
` 0.371
`
`287
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 309
`
`

`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 310
`
`

`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`30. Layer Management for 10 Mb/s and 100 Mb/s
`
`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 in 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.1B].
`
`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.1F-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.
`
`289
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 311
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`30.1.1 Scope
`
`SUPPLEMENT TO 802.3:
`
`This clause includes selections from 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 of AUI 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 into 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.1F-1993: ResourceTypeID, EWMAMetricMonitor.
`
`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.1, and 30A.2.1.
`
`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.
`
`290
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 312
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`This management standard, in conjunction with the management standards of other layers, provides the
`means to perform various management functions. 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/
`IEC 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.
`
`Manager
`
`Communicating
`Management Operations
`
`Notifications
`
`Agent
`
`Performing
`Management
`Operations
`
`Notifications
`Emitted
`
`Local system environment
`
`Managed
`Objects
`
`NOTE—Figure 1 of ISO/IEC 10040 has been reproduced with the permission of ISO. Copies of the complete
`standard may be obtained from the International Organization for Standardization, Case Postale 56, 1 rue de
`Varembé, CH-1211, Genève 20, Switzerland/Suisse.
`
`Figure 30-1—Interaction between manager, agent, and objects
`
`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)
`b)
`c)
`d)
`
`Attributes. Data-like properties (as seen by management) of a managed object.
`
`
`Actions. Operations that a managing process may perform on an object or its attributes.
`
`Notifications. Unsolicited reports of events that may be generated by an object.
`
`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.
`
`291
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 313
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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 functions
`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.
`
`292
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 314
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`oRepeaterMonitor
`
`oGroup
`
`oRepeaterPort
`
`oMAU
`
`oAutoNegotiation
`
`oResourceTypeID
`
`IEEE
`Std 802.3u-1995
`
`A managed object class called out by IEEE Std 802.1F-1993. See 30.1.2,
`oEWMAMetricMonitor.
`
`The group managed object class is a view of a collection of repeater ports.
`
`The repeater port managed object class provides a view of the functional
`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 from the port and control of the operation of the
`port. The Port Enable/Disable function 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 MII 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
`
`293
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 315
`
`