Additional reference material - pudn.comread.pudn.com/downloads104/doc/428917/802.3-2000_part5.pdf · Additional reference material [B1] ANSI/EIA 364A: ... ANSI/TIA/EIA 526-4A-1997

IEEECSMA/CD Std 802.3, 2000 Edition

Annex A

(informative)

Additional reference material

[B1] ANSI/EIA 364A: 1987, Standard Test Procedures for Low-Frequency (Below 3 MHz) Electrical Con-nector Test Procedure.

[B2] ANSI/EIA/TIA 455-30B-1991 (FOTP-30), Frequency Domain Measurement of Multimode OpticalFiber Information Transmission Capacity.

[B3] ANSI/EIA 455-34: 1985, Fiber Optics—Interconnection Device Insertion Loss Test.

[B4] ANSI/EIA/TIA 455-51A-1991 (FOTP-51), Pulse Distortion Measurement of Multimode Glass OpticalFiber Information, Transmission Capacity.

[B5] ANSI/EIA/TIA 455-54A-1990 (FOTP-54), Mode Scrambler Requirements for Overfilled LaunchingConditions to Multimode Fibers.

[B6] ANSI/EIA/TIA 455-59-1989, Measurement of Fiber Point Defects Using an Optical Time DomainReflectometer (ODTR).

[B7] ANSI/EIA 455-95-1986, Absolute Optical Power Test for Optical Fibers and Cables.

[B8] ANSI/EIA/TIA 455-127-1991 (FOTP-127), Spectral Characterization of Multimode Lasers.

[B9] ANSI/EIA/TIA 455-180-1990 (FOTP-180), Measurement of the Optical Transfer Coefficients of a Pas-sive Branching Device (Coupler).

[B10] ANSI/EIA/TIA 526-14-1990, Optical Power Loss Measurements of Installed Multimode Fiber CablePlant.

[B11] ANSI/IEEE Std 770X3.97-1983, IEEE Standard Pascal Computer Programming Language.67

[B12] ANSI/NFPA 70-1996, National Electrical Code.

[B13] ANSI/TIA/EIA 526-4A-1997 (OFSTP-4), Optical Eye Pattern Measurement Procedure.

[B14] ANSI/TIA/EIA 526-14A-1998, Optical Power Loss Measurements of Installed Multimode FiberCable Plant.

[B15] ANSI/TIA/EIA 526-7-1998, Measurement of Optical Power Loss of Installed Single-Mode FiberCable Plant.

[B16] ANSI/TIA/EIA-568-A-1995, Commercial Building Telecommunications Cabling Standard.

67ANSI/IEEE Std 770X3.97-1983 has been withdrawn; however, copies can be obtained from Global Engineering, 15 Inverness WayEast, Englewood, CO 80112-5704, USA, tel. (303) 792-2181.

Copyright © 2000 IEEE. All rights reserved. 1279

IEEEStd 802.3, 2000 Edition LOCAL AND METROPOLITAN AREA NETWORKS:

[B17] ANSI/TIA/EIA TSB95 (Proposed), Additional Transmission Performance Guidelines for 100 Ohm 4-Pair Category 5.

[B18] ANSI/UL 94-1990, Tests for Flammability of Plastic Materials for Parts in Devices and Appliances.

[B19] ANSI/UL 1950-1994, Safety Standard for Information Technology Equipment Including ElectricalBusiness Equipment.

[B20] ANSI X3.230-1994 (FC-PH), Information Technology—Fibre Channel—Physical and SignalingInterface.

[B21] ECMA-97 (1985), Local Area Networks Safety Requirements.

[B22] EIA CB8-1981, Components Bulletin (Cat 4) List of Approved Agencies, US and Other Countries,Impacting Electronic Components and Equipment.

[B23] FCC Docket 20780-1980 (Part 15), Technical Standards for Computing Equipment. Amendment ofPart 15 to redefine and clarify the rules governing restricted radiation devices and low-power communicationdevices. Reconsidered First Report and Order, April 1980.

[B24] IEC 60793-1-4: 1995, Optical fibres—Part 1: Generic specification—Section 4: Measuring methodsfor transmission and optical characteristics.

[B25] IEC 61754-4: 1997, Fibre optic connector interfaces—Part 4: Type SC connector family.

[B26] IEEE Std 610.7-1995, IEEE Standard Glossary of Computer Networking Terminology.

[B27] IEEE Std 802.9a-1995, IEEE Standards for Local and Metropolitan Area Networks: Integrated Ser-vices (IS) LAN: IEEE 802.9 Isochronous Services with Carrier Sense Multiple Access with Collision Detec-tion (CSMA/CD) Media Access Control (MAC) Service.

[B28] IEEE Std 1394-1995, IEEE Standard for a High-Performance Serial Bus.

[B29] MIL-C-17F-1983, General Specification for Cables, Radio Frequency, Flexible and Semirigid.

[B30] MIL-C-24308B-1983, General Specifications for Connector, Electric, Rectangular, Miniature Polar-ized Shell, Rack and Panel.

[B31] TIA/EIA TSB 67 (1995), Transmission Performance Specifications For Field Testing Of UnshieldedTwisted-pair Cabling Systems.

[B32] AMP, Inc., Departmental Publication 5525, Design Guide to Coaxial Taps. Harrisburg, PA 17105,USA.

[B33] AMP, Inc., Instruction Sheet 6814, Active Tap Installation. Harrisburg, PA 17105, USA.

[B34] Brinch, Hansen, P. The Architecture of Concurrent Programs. Englewood Cliffs, NJ: Prentice Hall,1977.

[B35] Digital Equipment Corporation, Intel, Xerox, The Ethernet, Version 2.0, November 1982.

[B36] Fiber Channel Jitter Working Group Technical Report, Rev. 1.0, Draft E. February 17, 1997.68

68This document is available via FTP at ftp://www.t11.org/t11/pub/fc/jitter_meth/98-055v5.pdf

1280 Copyright © 2000 IEEE. All rights reserved.


[B37] Hammond, J. L., Brown, J. E., and Liu, S. S. Development of a Transmission Error Model and ErrorControl Model. Technical Report RADC-TR-75-138. Rome: Air Development Center (1975).

[B38] Shoch, J. F., Dalal, Y. K., Redell, D. D., and Crane, R. C., “The Evolution of Ethernet,” ComputerMagazine, August 1982.

[B39] UL Subject No 758: UL VW-1, Description of Appliance Wiring Material.



Annex B

(informative)

System guidelines

B.1 Baseband system guidelines and concepts, 10 Mb/s

B.1.1 Overall system objectives

The CSMA/CD Access Method, supported by baseband technology, depends on a variety of analog systemcomponents at and below the physical level of the OSI Reference Model. These components provide basicinterconnection facilities for the CSMA/CD access mechanism itself and are defined throughout Clauses 6, 7,and 8.

Overall performance of the analog baseband medium and related physical layer capabilities depends on anoptimal and known set of analog capabilities within each of these critical system elements: the coaxial trunkcable, MAUs, branch cables, DTEs, and repeater units. These system elements affect the integrity with whichthe serial data bit stream analog signals are carried between open systems. There are at least three criticalparameters of interest: bits lost in the transmission system, signal delays, and phase jitter. It is important thatthese be apportioned properly among the affected system elements.

The successful interconnection of multivendor system components mandates that the values for bits lost, signaldelays, and phase jitter be allocated fairly and realistically among the various system elements. The balance ofAnnex B identifies the upper limits of values to be placed on the subject parameters. These values are based onthe maximal system configuration (for example, four repeater units, 2.5 km trunk coaxial cable medium).

B.1.2 Analog system components and parameter values

The values given in the following table are in terms of bits and are stated as maximum values except for val-ues given within ranges.

The initial mnemonic under each component entry refers to the system component as identified in Figure B–1.System parameters are stated in terms of the intralayer or interlayer messages sent within a station. Specificdelays are called out as = delay.

The repeater concepts described throughout this annex are considered to be an acceptable set of specifica-tions for a multirepeatered system. It is noted that the exact parametric values specified for the repeater envi-ronment are subject to minor refinement



.

Figure B–1 indicates the maximal system configuration and identifies the various system component param-eters considered critical in determining analog system performance.

Component and parameter Start-up delay

Last in tolast out delay

Start-up loss

MEDIUMTrunk Coaxial CableC1 Propagation 0.0 21.65 0.0

POINT TO POINT LINKP1 Propagation

AUIA1 Propagation

0.0

0.0

25.64

2.57

0.0

0.0

MEDIUM ACCESS UNITM1 DATA IN ASSERT → INPUTM2 OUTPUT → DATA OUT ASSERTM3 DATA IN COLLISION → SQE ASSERTM4 COLLISION DEASSERT → SQE DEASSERTM5 OUTPUT IDLE → SQE ASSERTM6 SQE TEST ASSERT → SQE DEASSERT

6.03.0

17.020.0

6 < × < 165 ≤ × ≤ 15

0.50.5————

5.02.0————

DTED1 INPUT → INPUT UNITD2 OUTPUT UNIT → OUTPUTD3 INPUT → CARRIER STATUS = CARRIER OND4 INPUT IDLE → CARRIER STATUS = OFFD5 SQE ASSERT → CARRIER STATUS = OND6 SQE DEASSERT → CARRIER STATUS = OFFD7 SQE ASSERT → SIGNAL STATUS = ERRORD8 SQE DEASSERT → SIGNAL STATUS = NO ERRORD9 CARRIER STATUS = OFF → OUTPUT UNIT

D10 INPUT → OUTPUT D11 SIGNAL STATUS = ERROR → JAM OUTPUT D12 JAM OUTPUT DURATION

18.0—3.0

3.0 < × ≤ 6.03.0

3.0 < × ≤ 6.03.0

3.0 < × ≤ 6.096 ≤ × ≤ 100

8.016.0

=32.0

—3.0——————————

18.0———————————

REPEATER UNITR1 INPUT 1,2 → OUTPUT 2,1R2 INPUT IDLE 1,2 → OUTPUT IDLE 2,1R3 INPUT 1,2 → CARRIER STATUS = ONR4 SQE → SOURCED OUTPUTR5 JAM OUTPUT → OUTPUT IDLE

7.5—3.06.5

=96.0

—12.5

———

22 < × < 34—————

Figure B–1—Maximal system configuration bit budget apportionments



B.1.3 Minimum frame length determination

The following table indicates the system elements that make up the minimum frame length calculation basedon the worst-case numbers as outlined in the bit budget of B.1.2. The compilation in the following table isbased on the following scenario:

a) DTE 1 transmits to an adjacent DTE 2 on coaxial segment 1.b) DTE 3 transmission collides with DTE 1 transmission.c) DTE 3 is assumed to be the worst-case distance from DTE 1 and its transmission just misses defer-

ring to the DTE 1 message.d) The collision fragment travels back down the network to inform DTE 1 that a collision has occurred

on its message.

The frame length is constrained by two parameters:

Component and function Direction Tableentry Delay Total

delay

DTE 1 STARTS TO PUT OUT FIRST BITDTE 1AUI M1MAU1COAX1

FWDFWDFWDFWD

D2A1M2C1

3.02.573.0

21.65

0.03.05.578.6

30.2

REPEATER SET 1MAU 1AAUI R1AREP 1AUI R1BMAU 1B

FWDFWDFWDFWDFWD

M1A1R1A1M2

6.02.577.52.573.0

36.238.846.348.951.9

REPEATER SET TOTAL 21.64

IRL 1REPEATER SET 2COAX 2REPEATER SET 3IRL 2REPEATER SET 4COAX 3MAU 3AUI 3DTE 3 PUTS OUT A BITAUI 3MAU 3COAX 3

FWDFWDFWDFWDFWDFWDFWDFWDFWDREVREVREVREV

P1

C1

P1

C1M1A1D10A1M2C1

25.6421.621.6521.625.6421.621.656.02.578.02.573.0

21.65

77.599.1

120.8142.4168.1189.7211.4217.4219.9227.9230.5233.5255.1

REPEATER SET 4MAU 4BAUI 4BREP 4AI 4AMAU 4A

REVREVREVREVREV

M3A1R4A1M2

17.02.576.52.573.0

272.1274.7281.2283.8286.8

REPEATER SET TOTALIRL 2REPEATER SET 3COAX 2REPEATER 2IRL 1REPEATER SET 1COAX 1MAU 1AUI M1DTE 1

REVREVREVREVREVREVREVREVREVREV

P1

C1

P1

C1M3A1D7

31.6425.6431.6421.6531.6425.6431.6421.6517.02.573.0

312.4344.1365.7397.4423.0454.6476.3493.3495.9498.9



— The message from DTE 1 shall be long enough so that it is still sending when the collision is detected.

— The message from DTE 1 shall be short enough such that DTE 2 can throw out the message on thebasis of being too short.

The above table provides the scenario that enables DTE 1 to determine a collision is taking place. DTE 1shall transmit for at least 499 bit times. To determine how much longer DTE 2 will continue to receive bits,assume that DTE 1 is the last transmitter to provide bits to the DTE 2 MAU. DTE 2 then sees the following:

If Repeater Set 1 is the last system component to provide bits to DTE 2, then DTE 2 will see the following:

The Repeater Set is the last transmitter to provide a bit to DTE 2. The DTE 2 MAU starts seeing bits at time8.6, which means that DTE 2 sees 563.7 bits (572.3 – 8.6). DTE 2 sees a minimum of 61 preamble bits and8 SFD bits. The preamble and SFD bits can be deleted from the 563.7 total because they are not counted inminimum frame length.

The minimum frame length determination from the above scenario is then 564.7 – 69.0 = 494.7 bits. The 10Mb/s system value for minimum frame length has been set at 512 bits.

B.1.4 System jitter budgets

The typical jitter budget expected for the baseband system is apportioned in the following manner:

The 18 ns jitter budget leaves adequate design margin for implementation-dependent considerations.

B.1.4.1 Nominal jitter values

The jitter budget values given above are not expected to accommodate all step changes in phase jitter due tosystem parameter variations within one or a few bit times.

Component and function Direction Table entry Delay Total delay

DTE 1DTE 1AUI M1

FWDFWDFWD

D11D12A1

16.032.02.57

514.9547.9549.4

Component and function Direction Table entry Delay Total delay

REPEATER SET 1 (1st JAM BIT)REP 1COAX 1

REVREV

R5C1

96.021.65

454.6550.6572.3

EncoderAUI CableMAU TransmitTrunk CoaxMAU ReceiveAUI CableSNR on COAXSNR on AUISNR on AUI

0.5 ns1.0 ns (transmit end)2.0 ns7.0 ns

–1.0 ns (with compensation)1.0 ns (receive end)5.0 ns (SNR = 5:1)0.5 ns (SNR = 5:1, transmit end)0.5 ns (SNR = 5:1, receive end)

16.5 ns



B.1.4.2 Decoder evaluation

The phase decoder in the PLS sublayer should correctly decode a Manchester-encoded signal whose datatransition point (center of a bit cell) has a peak-to-peak jitter of no more than 36 ns (± 18 ns deviation fromthe bit cell center). Figure B–2 and Figure B–3 show the test method.

Evaluation of decoder performance may be simulated and tested by application of three distinct waveformsrepresenting worst-case and normal conditions. The waveforms contain Manchester-encoded bits whosecenter transitions represent the extremes of maximum skew. A 5 MHz (repetition rate) pulse train whosepulse width is either 64 ns or 136 ns simulates the two worst-case jitter conditions. The data output from thedecoder should remain stable for each of the three test patterns and shifts between these extremes wherethere is a low rate of change in center transition skew. Note that the actual transmission system is notexpected to permit sudden drastic changes in the steady-state edge deviation during the reception of anygiven frame. The above evaluation process is not intended to guarantee proper decoder performance underall operating conditions.

Figure B–2—Typical signal waveforms

CENTER

18 ns

Ideal waveform at receiver

Allowed waveform at receiver

BIT CELL

18 ns

36 ns

Figure B–3—Worst-case signal waveform variations



B.1.5 Systems consideration calculations

B.1.5.1 Overview

Subclause B.1.3 contains a calculation of maximum fragment size for a network of 10BASE5 and IRL seg-ments. That calculation was based on the maximum delay for a transmission to reach the far end of the net-work and for a collision to propagate back. Since that calculation was written, many new media and MAUtypes have been added to this standard. Also, the calculation of B.1.3 did not address the interpacket gapshrinkage, which can limit the network size. It is not practical to perform a separate calculation for each pos-sible combination of segment types.

Some new segment types also support much longer media (up to 2 km). Introduction of longer media alsorequired a more flexible calculation method that allowed trading segment length for repeaters. The methodin this section was developed to meet these needs.

Actual numbers used to calculate delay and variability are tabulated (Table B–1) at the end of this subclause.

B.1.5.2 Maximum collision fragment size

The round-trip delay must be calculated to determine that collision will be received within the collision win-dow of transmitting DTEs and that collision fragments will be less than the minimum frame size. The fol-lowing scenario is used for the calculations (see Figure B–4):

a) DTE1 transmits.b) DTE1’s transmission propagates to DTE2.c) DTE2 begins transmitting at the last possible time, colliding and transmitting 96 bits.d) DTE2’s transmission propagates to DTE1.e) DTE1 detects collision, jams, and stops transmitting.

The following conditions must be met for proper network operation:

— DTE1 must detect collision before having transmitted the 512th bit (including preamble and SFDbits).

— DTE1 must stop transmitting before having transmitted a minimum length frame, 576 bits (512 bitsafter SFD).

— The overlap between DTE1’s transmission and DTE2’s transmission must be less than 575 bits (511bits after the SFD transmitted by DTE1).

For all existing segment types, the last condition is the limiting factor; if it is met then the other two condi-tions are also met.

The maximum time between the first bit and the last bit of the overlapping transmissions of the two DTEscolliding across a path will be called the Path Delay Value (PDV). Many factors contribute to this delay.Simplification of the delay calculation, as compared to the method used in B.1.3, can be achieved by using aset of base numbers, Segment Delay Values (SDV), for each segment type that combines the factors that con-tribute to the round-trip delay associated with that segment. The PDV is the sum of SDVs of the segmentsthat comprise the path.

For each segment type, one of three base SDVs is used depending on the position of the segment: left-end,mid-, or right-end. The left-end segment is connected to the DTE that transmits first (DTE1). The right-endsegment is connected to the colliding DTE (DTE2). All segments between these are mid-segments.

For this calculation, the left-end base SDV contains all delays from DTE1 through the MAU and its AUIconnected to the repeater unit. Each mid-base SDV includes the delays from the repeater unit on the left



through the MAU and its AUI connected to the right repeater unit. The right-end base SDV includes thedelays from the repeater unit immediately to its left through DTE2. (See Figure B–4.)

Only the bit loss of DTE1’s MAU on the left-end segment contributes to fragment size. The steady-statedelay of that MAU and the AUI cable delay do not contribute. For the remainder of the network, start-updelay (the sum of steady-state delay and bit loss) contribute. Therefore, the left-end base SDV uses MAUtransmit bit loss and 1 AUI delay. In all other cases, start-up delay and 2 AUI delays are used.

Propagation delays for media are not included in the base SDVs. These are added in separately to allow forvarious segment lengths (see 13.4.1). The base SDVs for the mid- and right-end segments (except 10BASE-FB) include two 2 m AUI cables and the delay of each one is experienced twice, once in the forward path andonce in the reverse path. Therefore, a delay of 0.5 BT per segment is added and corresponds to the round-tripdelay through two 2 m AUI cables. The base numbers for the left segment include one 2 m AUI cable,0.25 BT.

For each segment type, both the delay to transmission of the 96th bit after collision rise and delay to trans-mission of the last bit due to collision fall are calculated. The base SDV is the larger of these two.

The maximum allowed sum of SDVs plus media propagation delays is 575 BT.

B.1.5.2.1 Left-end base SDV

The Left-End Segment collision delay is the sum of the following:

Forward delay:

AUI

MAU transmit bit-loss delay

Media rise time

MAU receive start-up delay

Reverse delay:

MAU transmit fall delay after collision

MAU receive fall delay after collision

MAU

DTE 1

Repeater Repeater

MAU MAU MAU MAU MAU

DTE 2

AUI AUI AUI AUI AUI AUI

Left-End SDV Components Mid-SDV Components

Right-End SDV Components

Medium Medium Medium

Figure B–4—Round-trip delay calculation model



B.1.5.2.2 Mid-base SDV

The Mid-Segment collision rise delay is the sum of the following:

Forward delay:AUI * 2Repeater start-of-packet propagation delayMAU transmit start-up delayMedia rise timeMAU receive start-up delay

Reverse delay:MAU transmit start-up delayMAU collision detect delayRepeater start-of-collision propagation delay

The Mid-Segment collision fall delay is the sum of the following:

Forward delay:AUI * 2Repeater start-of-packet propagation delayMAU transmit start-up delayMedia rise timeMAU receive start-up delay

Reverse delay:MAU transmit fall delayMAU collision fall delayRepeater cessation-of-jam propagation delay

B.1.5.2.3 Right-end base SDV

The Right-End Segment collision rise delay is the sum of the following:

Forward delay:AUI * 2Repeater start-of-packet propagation delayMAU transmit start-up delayMedia rise timeMAU receive start-up delayDTE receive-to-transmit-not-deferred delay

Reverse delay:MAU transmit start-up delayMAU collision detect delayRepeater start-of-collision propagation delayRepeater minimum transmit length

The Right-End Segment collision fall delay is the sum of the following:

Forward delay:AUI * 2Repeater start-of-packet propagation delayMAU transmit start-up delay



Media rise timeMAU receive start-up delayDTE receive-to-transmit-not-deferred delayDTE minimum transmit length

Reverse delay:MAU transmit fall delayMAU collision fall delayRepeater cessation-of-jam propagation delay

B.1.5.3 Interpacket Gap (IPG) shrinkage

IPG shrinkage occurs because two successive packets may experience differing bit loss on the same path.When the packet passes through a repeater, the lost preamble bits are regenerated. If the first packet experi-ences greater bit loss than the second, the IPG between them will shrink.

IPG shrinkage is also calculated using a lumped number for each segment, the Segment Variability Value(SVV). For each segment type, one of two SVVs is used depending on the position of the segment: transmit-ting end or mid. The transmitting end segment is connected to the transmitting DTE or DTEs. The mid-seg-ments are all the remaining segments except the one connected to the receiving DTE.

The transmitting end segment and the mid-segment SVVs each include the variability from the transmittingMAU through the repeater unit. Since, IPG shrinkage only occurs when a repeater restores the lost bits, thefinal segment does not contribute any variability (see Figure B–5).

B.1.5.3.1 Transmitting end segment variability value

The transmitting end segment variability value is the sum of the following:MAU transmit start-up-delay variabilityMAU transmit start-up-delay variability correctionMAU receive start-up-delay variabilityMAU receive start-up-delay variability correctionRepeater start-of-packet propagation delay variabilityClock skew (2.5 BT)

NOTE—The variability correction values account for the possibility that on mixing segments the two successive packetscan be originated by two different MAUs.

DTE 2

MAU

DTE 1Repeater Repeater

MAU MAU MAU MAU MAU

AUI AUI AUI AUI AUI AUI

Medium Medium Medium

Transmitting EndSVV Components

Final SegmentNo SVV

Mid-SVVComponents

Figure B–5—Variability calculation model



B.1.5.3.2 Mid-segment variability value

The mid-segment variability value is the sum of the following:MAU transmit start-up-delay variabilityMAU receive start-up-delay variabilityRepeater start-of-packet propagation delay variability

B.1.5.4 Timing parameters for round-trip delay and variability calculations

Table B–1— contains the timing parameters used in the calculation of SDVs and SVVs. The values in thetable for MAU Collision Rise and MAU Collision Fall are those specific to the worst-case scenario. Theparameters are defined in the following subclauses.

B.1.5.4.1 MAU parameters

Transmit Bit Loss: Number of bits received on the DO circuit and not transmitted to the MDI.

Transmit Start-up Delay: Delay from the first bit received on the DO circuit to the first bit transmitted tothe MDI. This is the sum of transmit bit loss and steady-state delay.

Receive Start-up Delay: Delay from the first bit received on the MDI to the first bit transmitted to the DIcircuit. This is the sum of receive bit loss and steady-state delay.

Collision Detect Delay: Delay from the arrival of collision at the MDI to transmission ofsignal_quality_error to the CI circuit. For 10BASE2 and 10BASE5, this includes the DC rise time on themedia, given that the MAU has been transmitting for at least 20 BT when the collision arrives. For 10BASE-FP, this includes the delay until the second CRV occurs on the media (16.3.4.3).

Transmit Fall Delay: Delay from the last bit received on the DO circuit to the last bit transmitted to theMDI. This is the same as the steady-state delay.

Collision Fall Delay: Delay from arrival of end of collision at the MDI to end of transmission ofsignal_quality_error to the CI circuit. For 10BASE2 and 10BASE5, it includes the DC fall time of the media.For 10BASE-FP it includes the delay of 33 BT to pass with no more than one ORD_crv.

Transmit Start-up Delay Variability: Packet-to-packet variations in transmit start-up delay.

Transmit Start-up Delay Variability Correction: Additional variability, when the transmitting end seg-ment is a mixing segment, due to two MAUs transmitting with different start-up delays. For 10BASE5 and10BASE2, start-up delay variability plus transmit start-up delay variability correction equal transmit start-updelay since these MAUs may transmit with as little as 0 BT delay. For 10BASE-FP MAUs, implementationconsiderations imposed by the requirements of 16.3.1.1 require the MAU to have at least 2 BT start-up delay.Therefore, the transmit start-up delay variability correction equals the transmit start-up delay minus 2 BT.

Receive Start-up Delay Variability: Packet-to-packet variability in receive start-up delay.

Transmit Fall Delay After Collision: Delay from the last bit received on the DO circuit to the last bit trans-mitted to the MDI after the MAU has detected a collision. For all MAUs except 10BASE-FB, this is thesame as transmit fall delay.

Receive Fall Delay After Collision: Delay from the last bit received on the MDI to the last bit transmitted toDI. For all MAUs except 10BASE-FB and 10BASE-FP, this is the same as receive steady-state delay.



B.1.5.4.2 Repeater parameters

Start-of-Packet Propagation Delay: Delay from first bit received on DI to first bit transmitted on DO.

Start-of-Collision Propagation Delay: Delay from start of signal_quality_error on CI to first bit transmit-ted on DO.

Cessation-of-Jam Propagation Delay: Delay from end of signal_quality_error on CI to last bit transmittedon DO.

Minimum Transmit Length: Minimum delay from first bit transmitted on DO to last bit transmitted onDO.

Start-of-Packet Propagation Delay Variability: Packet-to-packet variation in start-of-packet propagationdelay.

B.1.5.4.3 Media parameters

Media Rise Time: Start-of-packet DC rise time on 10BASE2 and 10BASE5 segments.

B.1.5.4.4 DTE parameters

Receive-to-Transmit-Not-Deferred Delay: Delay from first bit on DI to first bit on DO when the DTEdoes not detect carrier in time to defer.

Minimum Transmit Length: Minimum delay from first bit transmitted on DO to last bit transmitted onDO.



Table B–1—Timing parameters for round-trip delay and variability calculations in bit times (BT)

Parameter 10BASE5

10BASE2 FOIRL 10BASE

-T10BASE-

FP10BASE-

FB10BASE-

FL

AUI (2 m) 0.25 0.25 0.25 0.25 0.25 0.00 0.25

MAU

Transmit bit loss 3.00 3.00 3.00 3.00 2.00 0.00 3.00

Transmit start-up delay 3.50 3.50 3.50 5.00 5.50 2.00 5.00

Receive start-up delay 6.50 6.50 3.50 8.00 2.50 2.00 5.00

Collision detect delay 17.00 17.00 3.50 9.00 9.50 3.50 3.50

Transmit fall delay 0.50 0.50 0.50 2.00 3.50 2.00 2.00

Collision fall delay 20.00 20.00 7.00 9.00 36.00 5.00 7.00

Transmit start-up delay variability

2.00 2.00 2.00 2.00 3.00 0.00 2.00

Transmit start-up delay variability correction

1.50 1.50 0.00 0.00 0.50 0.00 0.00

Receive start-up delay variability

5.00 5.00 2.00 2.00 1.00 0.00 2.00

Receive start-up delay variability correction

1.00 1.00 0.00 0.00 0.00 0.00 0.00

Transmit fall delay after collision

0.50 0.50 0.50 2.00 3.50 5.00 2.00

Receive fall delay after collision

0.50 0.50 0.50 2.00 3.00 5.00 2.00

REPEATER

Start-of-packet propa-gation delay

8.00 8.00 8.00 8.00 8.00 8.00 8.00

Start-of-collision propa-gation delay

6.50 6.50 6.50 6.50 6.50 6.50 6.50

Cessation-of-jam prop-agation delay

5.00 5.00 5.00 5.00 5.00 5.00 5.00

Minimum transmit length

96.00 96.00 96.00 96.00 96.00 96.00 96.00

Start-of-packet propa-gation delay variability

4.00 4.00 4.00 4.00 4.00 2.00 4.00

MEDIA RISE TIME 1.00 1.00 0.00 0.00 0.00 0.00 0.00

DTE

Receive-to-transmit-not-deferred delay

27.00 27.00 27.00 27.00 27.00 N/Aa 27.00

Minimum transmit length

96.00 96.00 96.00 96.00 96.00 N/Aa 96.00

aNot applicable; 10 BASE-FB does not support end (DTE) connections.



B.2 System parameters and budgets for 1BASE5

B.2.1 Delay budget

The successful interconnection of multivendor system components mandates that the values for bits lost andsignal delays be allocated fairly and realistically among the various system elements. The following tablesummarizes and indicates the derivation of some of the delays specified in 12.9. The breakdowns shown forthe parameters are illustrative only; implementors are free to make other allocations of delay within a deviceso long as the specifications of 12.9 are not violated.

Component Delay (BT)

DTE Initial Transmit Delay (see 12.9.2) 3

DTE Deference Delay (see 12.9.2) 21

unsquelch 3

Carrier detect 5

MAC detects carrier and defers 10

DTE Initial Transmit Delay 3

DTE Collision Shutdown Delay (see 12.9.2) 58

detect CP and report SIGNAL_ERROR 10

detect SIGNAL_ERROR and start jamming 16

jamSize 32

Medium Transit Delay (see 12.9.3) 4

Special Link Transit Delay (see 12.9.4) 15

Hub Startup Delay (see 12.9.5) 12

unsquelch 4

half fill FIFO 6

analogue of DTE Initial Transmit Delay 3

Hub Idle Collision Startup Delay (see 12.9.5) (same as Hub Startup Delay)

12

Hub Transit Delay (see 12.9.5) 9

half fill FIFO 6


Hub Delay Stretch/Shrink (see 12.9.5)((preamble + <sfd> + maxFrameSize) · 0.01% · 2)

3

Hub Collision Detect Delay (see 12.9.5) 21

unsquelch 3

detect collision 6

Hub Transit Delay 9

First CVL or CVH may be preceded by CD0s and CD1s 3

Hub Active Collision Startup Delay (see 12.9.5) 12

Hub Transit Delay 9

First CVL or CVH may be preceded by CD0s and CD1s 3

Hub Collision Shutdown Delay (downward) (see 12.9.5)(same as Hub Transit Delay)

9

Hub Collision Shutdown Delay (upward) (see 12.9.5) 25

detect loss of carrier 20

clear FIFO, if necessary 2




B.2.2 Minimum frame length determination

The minimum frame length for 1BASE5 is determined using the values specified in 4.4.2.2 and 12.9, appliedto the following (worst) case:

a) DTE 1, connected to Hub 1 at a network extremity, transmits a message upward toward Hub 5.b) There is a special link in the path between Hub 1 and Hub 5.c) DTE 2, also connected to Hub 1, transmits, just missing deferring to the downward signal from DTE

1 that was wrapped around at Hub 5.d) DTE 3, also connected to Hub 1, receives the transmission from DTE 1.e) Hub 1 generates CP, which travels up and then back down the network to inform DTE 1 and DTE 2

that a collision has occurred on their messages.f) DTE 1 and DTE 2 continue to transmit until they have received CP, reacted to it, and completed their

jams.g) DTE 3 continues to receive until the end of CP.

The minimum frame length must allow both of the following conditions to be met:

— DTE 1 is still sending when CP is received and recognized.— DTE 3 can discard the message fragment it receives because it is too short.

The minimum frame length must exceed both the maximum number of bits sent before recognizing CP (391– jamsize = 359) and the maximum collision fragment size (471), as computed above. The 1BASE5 system

Event Bits Total

DTE 1 → DTE 2DTE Initial Transmit Delay8 · Medium Transit Delay2 · Special Link Transit Delay10 · Hub Startup DelayDTE Deference Delay

33230

12021

33565

185206

DTE 2 → HUB 1 CPMedium Transit DelayHub Collision Detect Delay

421

210231

HUB 1 CP → HUB 5 CP3 · Medium Transit DelaySpecial Link Transit Delay4 · max(Hub Startup Delay,Hub Active Collision Startup Delay,Hub Idle Collision Startup Delay)

1215

48

243358

306

HUB 5 CP → DTE 1 receives CP5 · Hub Active Collision Startup Delay4 · Medium Transit DelaySpecial Link Transit Delay

601615

366382397

DTE 1 receives CP → DTE 1 stops transmitting DTE Collision Shutdown Delay 58 455

COMPUTATION OF MINIMUM FRAME SIZEoriginal preamble + <sfd>

5 · (Hub Collision Shutdown Delay (upward) – Hub Transit Delay)5 · (Hub Collision Shutdown Delay (downward) – Hub Transit Delay)

–64

800

391 = data bits

transmitted471471

Tiny fraction of Hub Delay Stretch/Shrink 0 471 = data bits received



value for minimum frame length has been set at 512 bits, which exceeds both of these values with a marginfor error.

B.2.3 Jitter budget

The total edge jitter of the signals on each link must be limited to allow proper decoding at the receiver. Thefollowing budget has been used to allocate jitter to the indicated components that contribute to the total jitteron each link:

The cable intersymbol interference and reflection allowances form the basis for the limit specified in12.7.2.3; the reflection component is sufficient to allow a single 20 Ω impedance mismatch anywhere alonga cable segment. The receiver-mismatch allowance is derived from the reflection attenuation specified in12.5.3.2.4. The total forms the basis for the specification in 12.5.3.2.2.

The remainder of the jitter that can be tolerated by the Manchester decoder in a receiver is reserved to allowfor distortion of the signal due to noise, receiver threshold offset, receiver skew, and receiver sampling tim-ing error.

A simple clocked receiver/decoder with an 8 MHz sampling rate (the worst case allowed for in the design ofthis standard), can achieve proper decoding with up to ± 125 ns of jitter between two edges, which is equiv-alent to ±62.5 ns on each edge. Other receiver designs may tolerate more edge jitter. For example, a 6 MHzsampling rate would allow up to ±83.33 ns of jitter on each edge and a 16 MHz sampling rate allows up to±93.75 ns of jitter.

It may be necessary to use a low-pass filter as part of the receiver to reduce the noise level seen by thatreceiver (see 12.7.4 for a description of the noise environment). A filter that reduces the noise may also havean effect on the amplitude and edge rate of the received signal. The filtered signal’s edge rate near the zero-crossing is used in the critical translation from mV of noise and receiver offset into ns of jitter.

An example receiver design using an 8 MHz sampling rate and a 2 MHz Butterworth input filter might bebased on the following jitter budget:

Component Jitter (ns)

Transmitter skew ±10

Cable intersymbol interference 9

Cable reflections 8

Reflections due to receiver termination mismatch 5

Total ±32

Component Jitter (ns)

Input jitter (from above) ±32

Noise and receiver threshold offset 19.5

Receiver skew (analog) 4

Receiver skew (digital) 7

Total ±62.5



The two primary contributors to noise in a 1BASE5 cable are self-crosstalk and impulse noise (see 12.7.4).Because it is unlikely that both will be present at their 1% worst-case levels on any particular cable, therequired bit error rate attributable to each source can be set at half of the one in 108 error rate required by12.5.3.2.6.

Crosstalk noise is specified to be no more than 105 mV (peak) through a 2 MHz filter (see 12.7.4.2).Because crosstalk is present for the entire transmission of a packet, some crosstalk will coincide with themost sensitive part of the received signal. Therefore, the receiver must operate without error in the presenceof this 105 mV of noise.

Impulse noise has a peak amplitude of 170 mV for ≤0.005 counts/s through the 2 MHz filter (see 12.7.4.1).This threshold does not directly correlate to jitter, however, because the derivation of the 62.5 ns jitter toler-ance for an 8 MHz clock assumed worst-case sampling error. Assuming a random phasing of the samplingclock to the received signals, it can be shown that the 170 mV of noise is equivalent to a level of 85 mV witha worst-phase clock.

Jitter due to noise should be computed using the larger of the above two levels. The 105 mV for crosstalknoise, therefore, should be added to 50 mV for receiver threshold offset and the result should be divided bythe edge rate of the filtered signal near the zero-crossing (7.9 mV/ns for the 2 MHz filter), yielding the19.5 ns indicated above.

B.3 Example crosstalk computation for multiple disturbers, balanced-pair cable

A method for computing multiple-disturber, near end, crosstalk attenuation (MDNEXT) into each 1BASE5pair is specified in 12.7.3.2. This annex provides example computations of MDNEXT using that methodwhen only the distribution of Xij is known.

The single-disturber probability distribution curve (labelled “1”) shown in Figure B–6 is based on actualmeasurement of 25-pair, 24-gauge, unshielded, twisted pair cable. The remaining probability distributioncurves (labelled with the number of disturbing pairs) were computed using Monte Carlo simulation. To com-pute each sample MDNEXTj for N disturbers, N values of crosstalk attenuation (Xi) were chosen from thesingle-disturber distribution and N values of crosstalk phase (θi) were chosen from a uniform distributionbetween 0 and 2π rad. These values were then used with the following equations to compute MDNEXTj:

Hj 10Xi/20–( )

1 i N≤ ≤ cosθi∑=

Vj 10Xi/20–( )

1 i N≤ ≤ sinθi∑=

MDNEXTj 10log10 Hj2

Vj2

+( )=



Iterating this process several hundred times, each time producing a single MDNEXTj sample, resulted in dis-tributions for MDNEXT that are summarized in the following table and Figure B–6:

Because two pairs are used for each 1BASE5 connection, the entries in this table for 18 and 24 disturbers arenot applicable for normal installation of 25-pair cables. Furthermore, telephone cables with larger numbersof pairs are often constructed using sub-bundles of 25 pairs each and so might yield similar results (forexample, the curves for 13 or fewer disturbers would be the most applicable ones).

The calculation method of this annex, though not the numeric values, applies to 10BASE-T.

Disturbers Iterations MDNEXT: Mean (dB) Std. Dev. (dB) 99% (dB)

1 61.2 7.0 48.6

2 500 57.2 6.2 46.4

3 500 55.1 5.8 45.2

6 500 52.0 5.7 42.5

13 1000 48.5 5.4 39.1

18 500 47.1 5.3 37.8

24 500 45.9 5.9 36.2

Figure B–6—MDNEXT cumulative probability distribution



B.4 10BASE-T guidelines

B.4.1 System jitter budget

The jitter budget for 10BASE-T is apportioned as follows:

NOTE—Total transmit jitter for the combination of the MAU transmitter and link segment (14.3.1.2.3) is ±3.5 ns and±8.0 ns for maximum- and short-length twisted-pair link segments, respectively. It is the sum of the entries for MAUtransmitter and twisted-pair medium with equalization. The individual components cannot be easily observed on MAUs.Short-length segment is defined as a short, non-zero-length twisted-pair link. A short- rather than a zero-length segmentis used in the calculation since a zero-length segment will have no significant noise and is a less severe case.

B.4.2 Filter characteristics

The implementation of the 3-pole, low-pass Butterworth filter should have the following characteristics:

This filter is only used for the tests described in 14.3.1.3.2, 14.4.4.1, and 14.4.4.2. A buffer may be needed toachieve the above return loss when using an LC implementation of this filter.

B.4.3 Notes for conformance testing

The following notes are provided to assist in developing the conformance test.

B.4.3.1 Notes for 14.3.1.2.1 on differential output voltage

For testing harmonics measured on the TD circuit when the DO circuit is driven by an all-ones Manchester-encoded signal, it is acceptable to use a pattern of maximum length packets whose data field is all ones.

For testing of the maximum and minimum output signal to the template in Figure 14–9, the recommendedmeasurement procedure is described as follows. An oscilloscope set for a zero voltage trigger with a positiveslope is allowed to accumulate an eye pattern that must be within the template. Acquisition must be long

Jitter budget Maximum-lengthtwisted-pair link

Short-lengthtwisted-pair link

(jitter expressed in ±ns)

Encoder 0.5 0.5

AUI cable including SNR (DO pair) 1.5 1.5

MAU transmitter 2.0 2.0

Twisted-pair medium with equalization 1.5 6.0

Noise jitter on twisted-pair medium 8.0 2.5

MAU receiver 1.5 1.5

AUI cable including SNR (DI pair) 1.5 1.5

Total 16.5 15.5

3 dB cutoff frequency 15 MHz

Insertion loss (5 MHz to 10 MHz) ≤1.0 dB

30 MHz attenuation ≥17.5 dB

Input impedance (5 MHz to 10 MHz) 100 Ω

Return loss with 100 Ω load (5 MHz to 10 MHz) ≥20 dB



enough to ensure that all data variations have been observed. When using packetized data, the TP_IDL andthe first transmitted bit should be excluded from this measurement. Also, the interpacket interval may beadjusted so that transition-to-idle transient effects are excluded. When testing with the inverted template, theslope of the scope trigger should be negative.

B.4.3.2 Note for 14.3.1.2.2 on transmitter differential output impedance

The return loss (RL) is defined as follows:

and also

where

Ztransmitter is the impedance of the transmitterZcable is the impedance of the cableVi is the differential voltage incident upon the transmitterVr is the differential voltage reflected from the transmitter

a) A transmitter with a purely resistive source impedance of 96 Ω ± 20% will satisfy this requirement.b) The requirement of 14.3.1.2.2 is equivalent to the following two constraints:

1) The return loss when measured with an 85 Ω resistive source is at least 15 dB in the frequencyrange of 5 MHz to 10 MHz.

2) The return loss when measured with a 111 Ω resistive source is at least 15 dB in the frequencyrange of 5 MHz to 10 MHz.

B.4.3.3 Note for 14.3.1.2.3 on output timing jitter

Adherence to the template of 14.3.1.2.1 with a jitterless source driving DO and the zero crossings con-strained to 46.5 ns to 53.5 ns and 96.5 ns to 103.5 ns is sufficient to demonstrate compliance with the 3.5 nsjitter requirement. When measuring an integrated MAU, the zero crossing time interval should be con-strained to 44.5 ns to 55.5 ns and 94.5 ns to 105.5 ns due to the additional allocation for encoder and AUI jit-ter. This test is simpler to perform than the test which follows, but failure of this test does not demonstratenoncompliance.

When triggering on one edge of the transmitted signal and observing another edge, the observed jitter mea-sures the difference between the jitter of the triggering edge and the observed edge. When the two edges areseparated such that the jitter of the edges is independent and clock drift is insignificant, the observed jitter istwice that of a single edge.

Therefore, a test that demonstrates compliance or noncompliance is as follows: Observe the zero crossings8 BT and 8.5 BT from the triggering zero crossing while transmitting a pseudo-random data sequence of atleast 511 bits. An external MAU with a jitterless source driving DO is compliant when all zero crossings fallwithin the time intervals 8.0 BT ± 7 ns and 8.5 BT ± 7 ns. An integrated MAU is compliant when all zerocrossings fall within the time intervals 8.0 BT ± 11 ns and 8.5 BT ± 11 ns.

RL 20log10

Ztransmitter Zcable+

Ztransmitter Zcable–-----------------------------------------------=

RL 20log10

Vi

Vr---------=



When using packetized data, the TP_IDL and the first transmitted bit should be excluded from these mea-surements.

B.4.3.4 General note on common-mode tests

When performing tests specified as balanced or common-mode, the balance of the test equipment (such asmatching resistors) must exceed that required by the test.

B.4.3.5 Note for 14.3.1.3.4 on receiver differential input impedance

The return loss (RL) is defined as follows:

and also

where

Zreceiver is the impedance of the receiver

Zcable is the impedance of the cable

Vi is the differential voltage incident upon the receiver

Vr is the differential voltage reflected from the receiver

a) A receiver with a resistive input impedance of 96 Ω ± 20% will satisfy this requirement.b) The requirement of 14.3.1.3.4 is equivalent to the following two constraints:

1) The return loss when measured with an 85 Ω resistive source is at least 15 dB in the frequencyrange of 5 MHz to 10 MHz.

2) The return loss when measured with a 111 Ω resistive source is at least 15 dB in the frequencyrange of 5 MHz to 10 MHz.

B.4.3.6 Note for 14.3.1.3.3 on receiver idle input behavior

For conformance testing of receivers, the start of idle shall conform to the template shown in Figure 14–10.Additionally, the magnitude of the voltage-time integral of the undershoot (measured from the negative zerocrossing that ends the positive idle pulse to the time when the differential signal settles to 0.0 mV ± 50 mV)shall be no greater than 1.2 times the voltage-time integral of the positive idle pulse (measured from the lastpositive zero crossing to the negative zero crossing).

B.4.3.7 Note for 14.3.1.3.5 on receiver common-mode rejection

For a stand-alone MAU, the receiver common-mode test may be performed with a jitterless Es, so that the DIcircuit should have no more than 4.0 ns of edge jitter.

For an integrated MAU, the common-mode test is performed with an Es that has zero crossing jitter up to 11 nsfrom the ideal.

RL 20log10

Zreceiver Zcable+

Zreceiver Zcable–------------------------------------------=

RL 20log10

Vi

Vr---------=



B.5 10BASE-F

B.5.1 System jitter budget

The jitter budgets for 10BASE-FP, 10BASE-FB, and 10BASE-FL are apportioned as shown in Table B–2.

B.5.2 10BASE-FP fiber optic segment loss budget

The 10BASE-FP MDI optical parameters specified in 15.2.1 and 15.2.2 have been selected to guaranteeoperation using a properly specified system of up to 500 m radius segment. This annex illustrates how the

Table B–2—System jitter budgets

Encoder 10BASE-FP 10BASE-FB 10BASE-FL

Encoder 0.5 0.5 0.5

AUI Cable including SNR (DO Pair)

1.5 N/A 1.5

MAU DO Receiver (10BASE-FP only)

2.0 N/A N/A

10BASE-FP Total at Retiming 4.0 N/A N/A

Subtotal (10BASE-FP Retimes)

0.0 0.5 2.0

Transmitter* 2.0 4.0 4.5

Subtotal (at the MDI) 2.0 4.5 6.5

Fiber Optic Medium 0.0 0.0 0.0

10BASE-FP Passive Star 0.0 N/A N/A

Fiber Optic Medium (10BASE-FP return)

0.0 N/A N/A

Receiver** 1.0 2.0 8.5

10BASE-FP Total at Retiming 3.0 N/A N/A

Subtotal (10BASE-FP Retimes)

0.0 6.5 15.0

Unallocated 8.5 10.0 0.0

MAU DI Transmitter (10BASE-FP only)

6.5 N/A N/A

AUI Cable incl-SNR (DI Pair) 1.5 N/A 1.5

Total 16.5 ns 16.5 ns 16.5 ns

*Includes jitter plus duty cycle distortion.

** 10BASE-FL figure includes MAU DI Transmitter jitter allocation.



loss budget may be allocated to star, optical fiber, and patch panel connectors, including examples at 100 mand 500 m radius.

The allowed system attenuation values are determined by the average transmit and receive power rangesspecified in Table 15–1. The average optical power launched into a 62.5 µm fiber must be greater than –15dBm and less than –11 dBm. (This includes any launch power variation and source degradation.) Receiveroperation is specified for average received power greater than –41 dBm and less than –27 dBm. Thus themaximum attenuation allowed for optical plant, including star, is 26 dB, and the minimum allowed attenua-tion is 16 dB.

This attenuation can be allocated between the star, fiber optic cable, and patch panel connectors in any man-ner as long as the maximum and minimum losses are within the limits stated in Table B–3. Note that the10BASE-FP Star insertion loss includes the loss of one optical connector pair as specified in 16.5.2.1.

Example 1: For a 500 m radius segment (1 km MDI to MDI) of 3.75 dB/km (measured at 850 nm) opticalfiber and a connector system with a maximum loss of 2 dB, the worst-case optical fiber and connector losswould be 5.75 dB. This would fall within the 6 dB limit, and result in a worst-case margin of 0.25 dB.

Example 2: A horizontal structured building wiring system (e.g., as detailed in ANSI/TIA/EIA-568-A-1995)of 100 m from the wiring closet to the desk top (100 m radius segment, 200 m MDI to MDI) of 3.75 dB/kmoptical fiber would have a loss of 0.75 dB. With four connector pairs in the path from MDI to MDI (wallplate, patch panel, patch panel, wall plate [see Figure 15–2]) and one connector pair at the 10BASE-FP Star(the other star connector pair is already included in the star loss [see 16.5.2.1)], and using a worst-case lossof 1 dB for each connector pair, the worst-case optical fiber and connector loss would be 5.75 dB. Thiswould fall within the 6 dB limit, and would result in a worst-case margin of 0.25 dB.

In addition to these loss budgets, the overall system return loss must be greater than 27 dB. The return loss isthe ratio of the desired signal to all undesired, multiple reflected signals, observed at a 10BASE-FP MAUMDI. Use of connectors with less return loss than specified in 15.3.2.2 as well as use of more than two patchpanels on each side of the star is permitted, as long as the overall system return loss requirement is met.

The 8.0 dB differential flux budget (16.3.4.2) can be allocated as shown in Table B–4.

Table B–3—10BASE-FP fiber optic segment loss budget

Item Min (dB) Max (dB)

Star 16 20

Fiber and Connectors 0 6

Totals 16 26

Table B–4—Eight decibel differential flux budget

Contribution (dB)

Variation at Star Input due to combined effects 4.8

1/2 star connector 0.5

Star including 1/2 connector 2.5

Wavelength in ORD leg 0.2

Total 8.0



Each of these contributions to the differential budget is a measurable quantity. For example, the variation inthe optical power at the star input due to combined effects of launch power, LED lifetime degradation, con-nectors, distance from 10BASE-FP MAU to Star, and wavelength of transmitter can be measured at the starinput port. Also, star differential loss measurement is described in 16.5.2.2.



Annex C

(informative)

State diagram, MAC sublayer

This annex was deleted by IEEE Std 802.3x-1997 and IEEE Std 802.3y-1997.



Annex D

(informative)

Application context, selected medium specifications

D.1 Introduction

This annex provides general guidance, to both the design engineer and the eventual user of specific productimplementations, on what particular clauses of the ISO/IEC 8802-3 International Standard might be consid-ered useful for different application environments. It is to be emphasized that the material in this annex isvery general, as the standard specifications are intended to be relatively application-independent. Neverthe-less, certain specifications may apply more to one application environment than another. What follows arebrief descriptions of application environments and lists of those generic parameters of the physical layerspecifications thought to be useful in relating a general set of user requirements to a specific standard speci-fication and its related medium. Once a basic relationship is identified, the reader is directed to a specificclause of the standard for detailed design specifications.

D.2 Type 10BASE5 applications

One of the major arenas for local area networks is the interconnection of work stations throughout a largedepartment or single building. The ability to handle all kinds of message traffic at relatively high data ratesamong a large set of work stations are typical characteristics of these environments. Usually the basic inter-connection trunk cable is installed and left in place permanently or for extended periods while work stationplacement may shift from time to time. The Type 10BASE5 specification provides the primary basebandbackbone for intraplant CSMA/CD interconnections. Clauses 7 and 8 of the standard provide detailed speci-fications for the physical layers associated with Type 10BASE5 environments. The generic physical layerparameters are as follows:

Maximum unrepeatered cable segment 500 mMaximum number of MAUs per segment 100Connector type Type N or coaxial “tap”Breakdown voltage, MAU function 250 V ac rmsMTBF 1 million hoursTotal Segment Resistance 5 ΩMAU separation 2.5 mConnection shunt capacitance 4 pFAUI functionality DO, DI, CI, (CO optional)

D.3 Type 10BASE2 applications

Another major arena for local area networks is the interconnection of work stations throughout a smalldepartment or work area. The ability to handle all kinds of message traffic at relatively high data rates amonga selected set of locally clustered work stations are the typical characteristics of these environments. In addi-tion, the basic interconnection trunk cable is likely to be moved frequently by the local users of the equip-ment to suit evolving needs. The Type 10BASE2 specification provides an interconnection schema thatcomplements the Type 10BASE5 backbone in a hierarchical manner for intradepartment or work areaCSMA/CD interconnections. Clauses 7 and 10 of the standard provide detailed specifications for the physi-



cal layers associated with Type 10BASE2 environments. The generic physical layer parameters are as fol-lows:

Maximum unrepeatered cable segment 185 mMaximum number of MAUs per segment 30Connector type Type BNC “T”Breakdown voltage, MAU function 500 V ac rmsMTBF 100 000 hoursTotal Segment Resistance 10 ΩMAU separation 0.5 mConnection shunt capacitance 8 pFAUI functionality DO, DI, CI

D.4 Type FOIRL and 10BASE-F Applications; alternative fiber optic medium applications

D.4.1 Alternative fiber types

Table D–1 provides a listing of other fiber types that may be used in an FOIRL or a 10BASE-F Cable LinkSegment. These fiber types have not been studied, and details for their use are not provided for in the mainbody of the standard. Therefore, using these fiber types may reduce the maximum achievable distance.

D.4.1.1 Theoretical coupling losses

The body of the standard references a single fiber type to facilitate interoperability and conformance testing;however, other fiber types may also be used. The use of an alternate fiber type with a particular implementa-tion may have the following consequences. At the transmit MDI, more or less light may be launched into thefiber, depending on whether the optics are optimized for a core size and a numerical aperture (NA) that aresmaller or larger than that of the alternate fiber size. At the receive MDI, the sensitivity may be increased ordecreased depending on the optimization of the collecting optics. Table D–2 summarizes the potentialeffects of the use of alternate fiber sizes and provides the loss budget remaining for cable plant attenuation.All adjustments are relative to an implementation using the minimum diameter and NA 62.5 µm core fiber asspecified in IEC 60793-2: 1992, Type A1b, Category ≤ 3.5 dB/km. This cable plant has a loss budget of 9 dBfor FOIRL segments and 12.5 dB for 10BASE-FL and 10BASE-FB link segments.

Table D–1—Alternative fiber types

Nominal Core diameter (µm) IEC 60793-2: 1992

Nominal cladding diameter (µm)

IEC 60793-2: 1992

Nominal Numerical apertureIEC 60793-2: 1992

50 125 0.2

50 125 0.21

50 125 0.22

85 125 0.26

100 140 0.29



The worst-case loss budget in Table D–2 is calculated on the assumption that the transmitter and receivercore diameter and NA are 62.5 µm and 0.275, respectively. Launching into a smaller core diameter or NAwill incur a loss. Launching into a larger core diameter or NA will not result in a gain.

Similarly, receiving from a larger core diameter or NA incurs a loss, but receiving from smaller core diame-ter or NA provides no gain.

The values for transmit powers assume a worst-case condition that no additional power is launched into anincreased core diameter and NA link fiber when referred to the 62.5 µm core fiber. This assumption is validfor underfilled launch conditions such as may occur from a MAU containing a pigtailed or laser emitter.

D.4.1.2 Maximum launch power

When large core diameter and NA launch conditions are used in conjunction with a launch fiber of largercore diameter and NA than the 62.5 µm reference, significantly greater launch power can occur. For exam-ple, this is typically the case with wide area surface emitter LED devices that are directly aligned with a fiberin a device mount header.

Table D–3 summarizes the maximum launch power into fibers with larger core diameters than 62.5 µm andthe corresponding excess power that can result with a receiver utilizing all the optical power from the fiber.

In this case, sufficient attenuation should be installed in the link segment to ensure that for FOIRL segmentsthe peak received optical power does not exceed –9 dBm, and for 10BASE-F segments the average receivedoptical power does not exceed the appropriate optical Receive Average Power (Max) in Table 15–1.

Table D–2—Worst-case loss budget

Fiber type Transmit loss (dB)

Receive loss (dB)

Loss budget remaining (dB)

FOIRL 10BASE-FB/L

50 µm/NA=0.20 5.7 0 3.3 6.8

50 µm/NA=0.21 5.2 0 3.8 7.3

50 µm/NA=0.22 4.8 0 4.2 7.7

85 µm/NA=0.26 1.6 2.6 4.8 8.3

100 µm/NA=0.29 0.5 4.5 4.0 7.5

Table D–3—Worst-case launch power

Fiber type Maximum transmit power (dBm)

Maximum excess power (dBm)

85 µm/NA=0.26 –6.1 2.9

100 µm/NA=0.29 –3.8 5.2



D.4.2 Type 10BASE-FP applications using 50/125 µm fiber

It is recognized that, in some cases, designers are constrained to use fiber sizes other than 62.5/125 µm inLAN designs. Such LAN designs are beyond the scope of this standard but can operate properly if opticalpower and loss budgets are adjusted to compensate for the different fiber characteristics. The followingguidance is provided for system implementors who are constrained to design LANs with the 50/125 µmfiber described in D.4.1.

D.4.2.1 Coupled transmit power

As shown in D.4.1, reduction of coupled power introduces the greatest difference between LANs using 62.5/125 µm and those using 50/125 µm fiber. Typically, for an emitter technology that produces a uniform, over-filled launch condition, this difference will be 3.5 dB. Implementors of 50/125 µm systems may choose todeal with this by trying one of the following alternatives:

a) Selecting an emitter technology with coupled power that is less susceptible to variation with fibersize, or

b) Increasing receiver sensitivity and dynamic range, or

c) Reducing the star coupler loss to compensate for the reduction in coupled transmit power. This maybe accomplished by reducing the number of ports on the star coupler, or

d) Reducing the connector losses in the system, either by reducing the number of in-line connectors orreducing the loss per connector.

D.4.2.2 Star coupler loss

Also in accordance with D.4.1, the transmission loss of 50/125 µm star couplers may be as much as 1 dBgreater than their 62.5/125 µm counterparts. Implementors of 50/125 µm systems may choose to deal withthis by trying one of the following alternatives:

a) Procurement—specification of coupler loss characteristics to be the same as those shown for 62.5/125 µm star couplers, per 16.5, or

b) Compensation—all items shown in D.4.2.1 a) to d) may be used to compensate for an increase incoupler loss.

For example, a passive-star coupler (with connectors) with 33 ports typically has the following losses:

Contributor Loss (dB)

Splitting: –15

Connector (1): –1

Excess: 0 to –4

Total: –16 to –20

WARNING

Interoperability of nonconforming implementations cannot be ensured. It is the responsibility of thedesigner(s) of nonconforming implementation(s) to assure LAN operation. The following is only advisoryinformation for implementations outside the scope of this standard.



If, in a LAN that used 50/125 µm fiber, the maximum allowable number of ports per passive-star couplerwas reduced to 17, the appropriate losses would be as follows:

The 3.5 dB lost to the MDI OTD would then be recovered allowing this “reduced nodes” LAN to still oper-ate at the proposed maximum of 500 m MAU to the star.

It should be noted that the MAU parameters remain unchanged.

D.4.2.3 Collision detection

Reliable collision detection requires that designers of systems using nonconforming fiber optic cable ensurethat the optical power levels of all possible colliding signals on the LAN differ at the mixing element (pas-sive-star coupler) by no more than that specified in 16.3.4.2. This requires that 10 * abs (log((PTi – LTi – UTi)/(PTj – LTj – UTj))) ≤ that specified in 16.3.4.2.

for all i not equal j, and

where

PTn is coupled optical transmit power, MAU n

LTn is optical cable and connector and transmit fiber loss, from MAU n to star input port m

UTm is input port uniformity, port m

D.5 10BASE-T use of cabling systems with a nominal differential characteristic impedance of 120 Ω

Clause 14 specifies the use of 100 Ω link segments. This subclause specifies the conditions for the use ofcabling with a nominal characteristic impedance of 120 Ω by 10BASE-T conformant stations.

The use of cables with a characteristic impedance outside the range specified in 14.4.2.2 will generallyincrease the mismatching effects in the link components, inducing additional jitter in the received signal.

In particular, the use of a homogeneous link segment having a characteristic impedance of 120 Ω ± 15 Ωover the frequency band 1 to 16 MHz may add from 0.15 ns (maximum-length segment) up to 0.63 ns(short-length segment) of additional jitter to the signal at the input of the receiver.

Consequently, in order to keep the overall jitter budget at the same value as for a 100 Ω link segment whenusing a 120 Ω link segment, the following modifications to the specifications of 14.4 apply:

a) The maximum medium timing jitter specified in 14.4.2.3 for a simplex link segment is increasedfrom 5 ns to 5.5 ns.

Contributor Loss (dB)

Splitting: –12

Connector (1): –1

Excess: 0 to –3

Total: –13 to –16



b) The NEXT loss values specified in 14.4.3 are increased by 3 dB, i.e., the applicable formulas arereplaced by the following:1) in 14.4.3.1.1 for 25-pair cables/binder groups: 33–15 log10(f/10) dB.2) in 14.4.3.1.2 for 4-pair cables: 29–15 log10(f/10) dB.3) in 14.4.3.2 for MDNEXT: 26–15 log10(f/10) dB.

NOTE—In addition to the case of 120 Ω homogeneous link segments, the above figures encompass the casewhere 100 Ω terminal cords are used in conjunction with 120 Ω premises cabling. This configuration results inadding up to 0.5 ns of jitter for a maximum-length segment (instead of 0.15 ns) and up to 1.3 ns for a short-length segment (instead of 0.63 ns).

The use of 100 Ω cords at any intermediate cross-connects on 120 Ω links as well as the use of cords with acharacteristic impedance of 120 Ω ± 15 Ω in conjunction with 100 Ω ±15 Ω premises cabling is not allowedsince it would result in worst-case jitter greater than that allowed in the standard.

D.6 10BASE-T use of cabling systems with a nominal differential characteristic impedance of 150 Ω

This subclause outlines the philosophy and methodology for allowing 10BASE-T stations to support trans-mission on 150 Ω balanced STP cabling, installed in accordance with ANSI/TIA/EIA-568-A-1995 [B16],Clause 4, and ISO/IEC 11801: 1995, Clause 8, with the use of impedance matching transformers.

The 10BASE-T specification was designed to support Manchester signaling over a link segment consistingof 100 Ω cabling system. The MAU link interface specifications were designed to ensure that jitter due toimpedance discontinuities were minimized as specified in 14.4.2.3. In theory and in practice, a 150 Ωcabling system may be used to provide the link segment function provided the proper impedance match(100 Ω) with the MAU over the frequency range of interest as specified in 14.4, and the resultant transmis-sion characteristics of the cabling system used to provide the link segment function meet or exceed thosespecified in 14.4. Therefore, to ensure the jitter specification of 14.4.2.3 and the jitter budget of B.4.1 aremet, the following approach is recommended when using 150 Ω balanced STP cabling (as specified in ISO/IEC 11801: 1995):

a) The 150 Ω section included in the link segment shown in Figure D–1 meets the specifications ofISO/IEC 11801: 1995, 7.2, and ANSI/TIA/EIA-568-A-1995 [B16].

XFMR XFMR MDIMDI 100 Ω150 Ω

100 Ω : 150 Ω 150 Ω : 100 Ω

100 Ω

TWISTED PAIR LINK SEGMENT

Figure D–1—Link segment incorporating 150 Ω cable section



b) The link segment, including impedance matching transformers as shown in Figure D–2, meets allapplicable specifications of 14.4.

c) A link test point is shown in Figure D–2. The transformers shown are the same as the ones shown inFigure D–1. The attaching cables between the MAU and the link test point should be the minimumrequired to attach the components. As tested in this configuration, the MAU transmitter requirementsmeet all applicable requirements for the MAU as specified in Clause 14, except for signal levelswhich may be up to 1.0 dB lower than that specified there.

NOTE—This 1.0 dB (0.5 dB per transformer) effectively requires the attenuation of the 150 Ω cable section of thetwisted-pair link segment (see Figure D–1) to be less than or equal to 10.5 dB in order to meet the requirements of14.4.2.

XFMR XFMR

100 Ω : 150 Ω 150 Ω : 100 Ω

MAU Link Test Point

Figure D–2—Link test point for 150 Ω cabling



Annex E

(informative)

Receiver wavelength design considerations (FOIRL)

The center wavelength of the optical source emission is specified in 9.9.4.1.1 to be between 790 nm and860 nm. Although these limits are acceptable, it is currently recognized, through the examination of manu-facturers’ current data, that greater choices of emitters can be obtained by extending the allowable wave-length to 910 nm.

An upper limit of 910 nm allows the selection of devices nominally centered at a lower wavelength, forexample, 880 nm. This allows a tolerance for manufacturing variations, for example, ±20 nm, and a toler-ance for an operating temperature range (typically, 0.3 nm/°C).

It is anticipated that future fiber optic applications including Local Area Networks will use the 910 nm upperlimit for first window systems. It is therefore recommended that implementors specify receiver sensitivityover a center wavelength range from 790 nm to 910 nm.



Annex F

(normative)

Additional attributes required for systems

F.1 Introduction

During the development of Repeater Management, some attributes and operations were identified as itemsthat were necessary to fill out the management of a complete intermediate system such as a repeater. Theseitems are generic in the sense that they are required for managed systems in general. They are not normallyspecified as attributes of the lower layers. In repeater management, the entire system is at the lowest layersso there is no other group to turn to for systems management. The following items are defined to aid in thecompleteness of this standard, although it is recognized that they are outside the bounds of the definitionarea for a layer1/2 device.

F.1.1 Scope

This annex defines additional managed objects and attributes that have been identified by the 802.3 RepeaterManagement Task Force as being necessary to the management of an 802.3 repeater. These objects andattributes, while necessary to the management of an 802.3 repeater, are not specifically related to the CSMA/CD access method or to Clause 9 repeaters; rather, they are objects and attributes that are appropriate for anymanaged system.

This annex does not necessarily define the complete set of generic objects and attributes required to supporta managed system. It contains only those objects and attributes that were identified in the process of devel-oping the repeater management standard and were identified as not being uniquely appropriate to a CSMA/CD layer management standard.

When a generic systems management standard is available that is appropriate for managed systems of thecomplexity of a repeater, it is expected that this portion of the standard will no longer be appropriate and willbe deprecated.

F.2 Objects/Attributes/Actions/Notifications

F.2.1 TimeSinceSystemReset attribute

aTimeSinceSystemReset ATTRIBUTE

DERIVED FROM AttributeModule.ResettableCounter32;

BEHAVIOUR bTimeSinceSystemReset;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) attribute(7) sysResetTime(47);



bTimeSinceSystemReset BEHAVIOURDEFINED AS The time in tens of milliseconds since the last time that the system including

network management was reset. This may have been caused by ResetSystemAction or other means. This counter has a value of 0 when initialized.

Though the count is reported in tens of milliseconds, the required resolution is to the nearest 100 ms. The clocking source for the counter shall be accurate to within 1% throughout the full counting range.;

NOTE—The approximate minimum time for counter rollover is 497 days.

F.2.2 RepeaterResetTimeStamp attribute

aRepeaterResetTimeStamp ATTRIBUTEWITH ATTRIBUTE SYNTAX AttributeModule.Integer32;BEHAVIOUR bRepeaterResetTimeStamp;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) attribute(7)

repeaterResetTimeStamp(48);

bRepeaterResetTimeStamp BEHAVIOURDEFINED AS Not a counter, this attribute provides the value of

aTimeSinceSystemReset when the repeater was last reset. This value is recorded whenever the repeater enters the START state of Figure 9-2 in the 802.3 repeater standard. This value may never be greater than aTimeSinceSystemReset.;

F.2.3 ResetSystemAction action

acResetSystemAction ACTIONBEHAVIOUR acResetSystem;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) action(9)

resetSystem(49);

acResetSystem BEHAVIOURDEFINED AS This action initializes the resettable management counters of the system and

also of all contained objects. The value of non-resettable counters may change as a result of this action.;

NOTE—This action may result in the loss of packets.



Annex G

(normative)

Additional material required for conformance testing

G.1 Introduction

This material was generated during the development of Clause 19. It was felt that it was required to supportthe development of conformance test material that was not included in the charter of the development of theoriginal repeater management standard.

G.1.1 Material in support of the aDataRateMismatches attribute

A vendor submitting equipment for conformance testing under Clause 19 shall provide minimum frequencydifference data (two values) such that a test can be done for exertion and another test can be done for non-exertion of the aDataRateMismatch attribute (see 19.2.6.2).



Annex H

(normative)

GDMO specifications for CSMA/CD managed objects

H.1 Use of MAC and PLS Sublayer Management Definitions with CMIS/CMIP and ISO/IEC 15802-2: 1995 Management Protocols

NOTE—The arcs (that is, object identifier values) defined in Annex 30A deprecate the arcs previously defined in H.1(Layer Management), H.2 (Repeater Management), and H.3 (MAU Management). See IEEE Std 802.1F-1993, AnnexC4.

This annex clause formally defines the protocol encodings for CMIP and ISO/IEC 15802-2: 1995 for theDTE Management objects using the templates specified in ISO/IEC 10165-4: 1992.

Each attribute definition in this clause references directly by means of the WITH ATTRIBUTE SYNTAXconstruct or indirectly by means of the DERIVED FROM construct an ASN.1 type or subtype that definesthe attribute’s type and range. Those ASN.1 types and subtypes defined exclusively for CSMA/CD Manage-ment are included in H.4.

H.1.1 DTE MAC sublayer managed object class

H.1.1.1 DTE MAC sublayer formal definition

oMAC-entity MANAGED OBJECT CLASSDERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 :

1992”:top;CHARACTERIZED BY

pBasic PACKAGEATTRIBUTES aMACID GET;ACTIONS acInitializeMAC;

;;CONDITIONAL PACKAGES

pMandatory PACKAGEATTRIBUTES aFramesTransmittedOK GET,

aSingleCollisionFrames GET,aMultipleCollisionFrames GET,aFramesReceivedOK GET,aFrameCheckSequenceErrors GET,aAlignmentErrors GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) package(4) macMandatoryPkg(103);

PRESENT IF Conformance to DTE Management is desired.;pRecommended PACKAGE

ATTRIBUTES aOctetsTransmittedOK GET,aFramesWithDeferredXmissions GET,aLateCollisions GET,aFramesAbortedDueToXSColls GET,aFramesLostDueToIntMACXmitError GET,



aCarrierSenseErrors GET,aOctetsReceivedOK GET,aFramesLostDueToIntMACRcvError GET,aPromiscuousStatus GET-SET,aReadMulticastAddressList GET;

ACTIONS acAddGroupAddress,acDeleteGroupAddress;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) package(4) macRecommendedPkg(104);

PRESENT IF The Recommended Package is implemented.;pOptional PACKAGE

ATTRIBUTES aMulticastFramesXmittedOK GET,aBroadcastFramesXmittedOK GET,aMulticastFramesReceivedOK GET,aBroadcastFramesReceivedOK GET,aInRangeLengthErrors GET,aOutOfRangeLengthField GET,aFrameTooLongErrors GET,aMACEnableStatus GET-SET,aTransmitEnableStatus GET-SET,aMulticastReceiveStatus GET-SET,aReadWriteMACAddress GET-SET;

ACTIONS acExecuteSelfTest;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmadtemgt(5) package(4) optionalPkg(105);PRESENT IF The Optional Package and the Recommended Package is

implemented.;pArray PACKAGE

ATTRIBUTES aCollisionFrames GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmadtemgt(5) package(4) arrayPkg(106;PRESENT IF The Array Package and the Recommended Package are

implemented.;pExcessiveDeferral PACKAGE

ATTRIBUTES aFramesWithExcessiveDeferral GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmadtemgt(5) package(4) excessiveDeferralPkg(107);

PRESENT IF The ExcessiveDeferral Package and the Recommended Package are implemented.;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) managedObjectClass(3) macObjectClass(101);

nbMACName NAME BINDINGSUBORDINATE OBJECT CLASS oMAC-entity;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system;WITH ATTRIBUTE aMACID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

nameBinding(6) macName(109);

nbMACMonitor NAME BINDINGSUBORDINATE OBJECT CLASS “IEEE802.1F”:ewmaMetricMonitor;



NAMED BY SUPERIOR OBJECT CLASS“ISO/IEC 10165-2”:system;

WITH ATTRIBUTE aScannerId;

CREATE WITH-AUTOMATIC-INSTANCE-NAMING;DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) nameBinding(6) macMonitor(110);

H.1.1.2 DTE MAC sublayer attributes

aMACID ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;

MATCHES FOR EQUALITY;

BEHAVIOUR bMACID;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) attribute(7) macID(114);

bMACID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.1.;

aFramesTransmittedOK ATTRIBUTEDERIVED FROM aLMCounter;

BEHAVIOUR bFramesTransmittedOK;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) attribute(7) framesTransmittedOK(115);

bFramesTransmittedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.2.;

NOTES1—The approximate minimum time between counter rollovers is 80 h.;2—This maps to framesSent (of the mandatory macPackage) in ISO/IEC 10742: 1994.;

aSingleCollisionFrames ATTRIBUTEDERIVED FROM aLMCounter;

BEHAVIOUR bSingleCollisionFrames;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) attribute(7) singleCollisionFrames(116);

bSingleCollisionFrames BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.3.;

NOTE—The approximate minimum time between counter rollovers is 103 h.;

aMultipleCollisionFrames ATTRIBUTEDERIVED FROM aLMCounter;

BEHAVIOUR bMultipleCollisionFrames;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) attribute(7) multipleCollisionFrames(117);

bMultipleCollisionFrames BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.4.;


aFramesReceivedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesReceivedOK(118);bFramesReceivedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.5.;

NOTES1—The approximate minimum time between counter rollovers is 80 h.;2—This maps to framesReceived (of the mandatory macPackage) in ISO/IEC 10742: 1994.;

aFrameCheckSequenceErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFrameCheckSequenceErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) frameCheckSequenceErrors(119);

bFrameCheckSequenceErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.6.;


aAlignmentErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bAlignmentErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) alignmentErrors(120);

bAlignmentErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.7.;


aOctetsTransmittedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bOctetsTransmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) octetsTransmittedOK(121);

bOctetsTransmittedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.8.;

NOTES1—The approximate minimum time between counter rollovers is 58 min.2—This maps to octetsSent (of the mandatory macPackage) in ISO/IEC 10742: 1994.;



aFramesWithDeferredXmissions ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesWithDeferredXmissions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesWithDeferredXmissions(122);

bFramesWithDeferredXmissions BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.9.;


aLateCollisions ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bLateCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) lateCollisions(123);

bLateCollisions BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.10.;


aFramesAbortedDueToXSColls ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesAbortedDueToXSColls;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesAbortedDueToXSColls(124);

bFramesAbortedDueToXSColls BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.11.;

NOTE—The approximate minimum time between counter rollovers is 53 days.;

aFramesLostDueToIntMACXmitError ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesLostDueToIntMACXmitError;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesLostDueToIntMACXmitError(125);

bFramesLostDueToIntMACXmitError BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.12.;


aCarrierSenseErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bCarrierSenseErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) carrierSenseErrors(126);

bCarrierSenseErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.13.;




aOctetsReceivedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bOctetsReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) octetsReceivedOK(127);bOctetsReceivedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.14.;

NOTES1—The approximate minimum time between counter rollovers is 58 min.2—This maps to octetsReceived (of the mandatory macPackage) in ISO/IEC 10742: 1994.;

aFramesLostDueToIntMACRcvError ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesLostDueToIntMACRcvError;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesLostDueToIntMACRcvError(128);

bFramesLostDueToIntMACRcvError BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.15.;


aPromiscuousStatus ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

TrueFalse;BEHAVIOUR bPromiscuousStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) promiscuousStatus(129);

bPromiscuousStatus BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.16.;

aReadMulticastAddressList ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

MulticastAddressListBEHAVIOUR bReadMulticastAddressList;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) readMulticastAddressList(130);

bReadMulticastAddressList BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.17.;

aMulticastFramesXmittedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bMulticastFramesXmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) multicastFramesXmittedOK(131);

bMulticastFramesXmittedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.18.;




aBroadcastFramesXmittedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bBroadcastFramesXmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) broadcastFramesXmittedOK(132);

bBroadcastFramesXmittedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.19.;


aFramesWithExcessiveDeferral ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFramesWithExcessiveDeferral;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) framesWithExcessiveDeferral(133);

bFramesWithExcessiveDeferral BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.20.;


aMulticastFramesReceivedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bMulticastFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) multicastFramesReceivedOK(134);

bMulticastFramesReceivedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.21.;


aBroadcastFramesReceivedOK ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bBroadcastFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) broadcastFramesReceivedOK(135);

bBroadcastFramesReceivedOK BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.22.;


aInRangeLengthErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bInRangeLengthErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) inRangeLengthErrors(136);

bInRangeLengthErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.23.;




aOutOfRangeLengthField ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bOutOfRangeLengthField;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) outOfRangeLengthField(137);bOutOfRangeLengthField BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.24.;


aFrameTooLongErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bFrameTooLongErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) frameTooLongErrors(138);

bFrameTooLongErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.25.;


aMACEnableStatus ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

TrueFalse;BEHAVIOUR bMACEnableStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) mACEnableStatus(139);

bMACEnableStatus BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.26.;

aTransmitEnableStatus ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

TrueFalse;BEHAVIOUR bTransmitEnableStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) transmitEnableStatus(140);

bTransmitEnableStatus BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.27.;

aMulticastReceiveStatus ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

TrueFalse;BEHAVIOUR bMulticastReceiveStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) multicastReceiveStatus(141);

bMulticastReceiveStatus BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.28.;

aReadWriteMACAddress ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802CommonDefinitions.MACAddress;BEHAVIOUR bReadWriteMACAddress;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) attribute(7) modifyMACAddress(142);

bReadWriteMACAddress BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.29.;

NOTE—This maps to localMACAddress (of the mandatory macPackage) in ISO/IEC 10742: 1994.;

aCollisionFrames ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

AttemptArray;BEHAVIOUR bCollisionFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) collisionFrames(143);

bCollisionFrames BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.1.30.;

NOTE—The approximate minimum time for any single counter rollover is 103 h.;

H.1.1.3 DTE MAC sublayer actions

acInitializeMAC ACTIONBEHAVIOUR bInitializeMAC;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

action(9) initializeMAC(146);

bInitializeMAC BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.2.1.;

acAddGroupAddress ACTIONBEHAVIOUR bAddGroupAddress;MODE CONFIRMED;WITH INFORMATION SYNTAX IEEE802CommonDefinitions.MACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

action(9) addGroupAddress(147);

bAddGroupAddress BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.2.2.;

acDeleteGroupAddress ACTIONBEHAVIOUR bDeleteGroupAddress;MODE CONFIRMED;WITH INFORMATION SYNTAX IEEE802CommonDefinitions.MACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

action(9) deleteGroupAddress(148);

bDeleteGroupAddress BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.2.3.;

acExecuteSelfTest ACTIONBEHAVIOUR bExecuteSelfTestMAC;



MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

action(9) executeSelfTestMAC(149);

bExecuteSelfTest BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.2.2.4.;

H.1.2 ResourceTypeID managed object class

H.1.2.1 ResourceTypeID, formal definition

-- Implementation of this managed object in accordance with the definition contained in -- IEEE Std 802.1F-1993 is a conformance requirement of this standard.-- NOTE—A single instance of the Resource Type ID managed object exists within the -- DTE–MAC managed object class. The managed object itself is contained in IEEE Std 802.1F-1993; -- therefore, only the name binding appears in this standard;

nbResourceTypeID NAME BINDINGSUBORDINATE OBJECT CLASS “IEEE802.1F”:oResourceTypeID;NAMED BY SUPERIOR OBJECT CLASS

oMAC-Entity;WITH ATTRIBUTE “IEEE802.1F”:aResourceTypeIDName;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

nameBinding(6) resourceTypeID(111);

H.1.3 DTE physical layer managed object class

H.1.3.1 DTE physical layer formal definition

oPHY-entity MANAGED OBJECT CLASSDERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 :


pMandatory PACKAGE--There are no mandatory Attributes, Actions, or Notifications;--therefore, management of this object is not required if only--the mandatory package is implemented.


pRecommended PACKAGEATTRIBUTES aPHYID GET,

aSQETestErrors GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmadtemgt(5) package(4) phyRecommendedPkg(108);

PRESENT IF The Recommended Package is implemented.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

managedObjectClass(3) phyObjectClass(102);

nbPHYName NAME BINDINGSUBORDINATE OBJECT CLASS oPHY-entity;NAMED BY SUPERIOR OBJECT CLASS



oMAC-entity;;WITH ATTRIBUTE aPHYID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

nameBinding(6) phyName(112);

nbPHYMonitor NAME BINDINGSUBORDINATE OBJECT CLASS “IEEE802.1F”:ewmaMetricMonitor;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system;WITH ATTRIBUTE aScannerId;


REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5) nameBinding(6) phyMonitor(113);

H.1.3.2 DTE physical sublayer attributes

aPHYID ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bPHYID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) phyID(144);

bPHYID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.3.1.1;

aSQETestErrors ATTRIBUTEDERIVED FROM aLMCounter;BEHAVIOUR bSQETestErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmadtemgt(5)

attribute(7) sqeTestErrors(145);

bSQETestErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 5.2.3.1.2.;


H.2 GDMO specification for Repeater Management Object Class


This subclause formally defines the Repeater Management Objects using the templates specified in ISO/IEC10165-4: 1992.

The protocol encodings for CMIP, and therefore ISO/IEC 15802-2: 1995 can be derived from H.2.1 to H.2.5directly. The template defined in ISO/IEC 10165-4 specifies precisely the syntax used in this document todefine the operation, objects and attributes. The application of a GDMO template compiler against H.2.1 toH.2.5 will produce the proper protocol encodings.



Each attribute definition in this clause references directly by means of the WITH ATTRIBUTE SYNTAXconstruct or indirectly by means of the DERIVED FROM construct an ASN.1 type or subtype that definesthe attribute’s type and range. Those ASN.1 types and subtypes defined exclusively for CSMA/CD Manage-ment are appear in a single ASN.1 module in Annex H.

H.2.1 Repeater managed object class

H.2.1.1 Repeater, formal definition

oRepeater MANAGED OBJECT CLASSDERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2


pRepeaterBasicControl PACKAGEATTRIBUTES aRepeaterID GET,

aRepeaterGroupCapacity GET,aGroupMap GET,aRepeaterHealthState GET,aRepeaterHealthText GET,aRepeaterHealthData GET;

ACTIONS acResetRepeater,acExecuteNonDisruptiveSelfTest;

NOTIFICATIONS nRepeaterHealth,nRepeaterReset,nGroupMapChange;


pRepeaterPerfMonitor PACKAGEATTRIBUTES aTransmitCollisions GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

repeaterMgt(19) package(4) repeaterPerfMonitorPkg(4);

PRESENT IF The Performance Monitor Capability is implemented.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

managedObjectClass(3) repeaterObjectClass(1);

nbRepeaterName NAME BINDINGSUBORDINATE OBJECT CLASS repeater;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system AND SUBCLASSES;WITH ATTRIBUTE aRepeaterID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

nameBinding(6) repeaterName(7);

nbRepeaterMonitor NAME BINDINGSUBORDINATE OBJECT CLASS “IEEE802.1F”:oEWMAMetricMonitor;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system AND SUBCLASSES;WITH ATTRIBUTE aScannerId;CREATE WITH-AUTOMATIC-INSTANCE-NAMING;DELETE ONLY-IF-NO-CONTAINED-OBJECTS;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)



nameBinding(6) repeaterMonitor(8);

H.2.1.2 Repeater attributes

aRepeaterID ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) repeaterID(13);

bRepeaterID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.1.;

aRepeaterGroupCapacity ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bRepeaterGroupCapacity;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) repeaterGroupCapacity(14);

bRepeaterGroupCapacity BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.2.;

aGroupMap ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

BitString;MATCHES FOR EQUALITY;BEHAVIOUR bGroupMap;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) groupMap(15);

bGroupMap BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.3.;

aRepeaterHealthState ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

RepeaterHealthState;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) repeaterHealthState(16);

bRepeaterHealthState BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.4.;

aRepeaterHealthText ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

RepeaterHealthText;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthText;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) repeaterHealthText(17);



bRepeaterHealthText BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.5.;

aRepeaterHealthData ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

RepeaterHealthData;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthData;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) repeaterHealthData(18);

bRepeaterHealthData BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.6.;

aTransmitCollisions ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bTransmitCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) transmitCollisions (19);

bTransmitCollisions BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.2.7.;

NOTE—The approximate minimum time for counter rollover is 16 h.;

H.2.1.3 Repeater actions

acResetRepeater ACTIONBEHAVIOUR bResetRepeater;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

action(9) resetRepeater(40);

bResetRepeater BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.3.1.;

acExecuteNonDisruptiveSelfTest ACTIONBEHAVIOUR bExecuteNonDisruptiveSelfTest;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

action(9) executeNonDisruptiveSelfTestAction(41);

bExecuteNonDisruptiveSelfTest BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.3.2.;

H.2.1.4 Repeater notifications

nRepeaterHealth NOTIFICATIONBEHAVIOUR bRepeaterHealth;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

RepeaterHealthInfoAND ATTRIBUTE IDS fnRepeaterHealthState aRepeaterHealthState,

fnRepeaterHealthText aRepeaterHealthText, fnRepeaterHealthData aRepeaterHealthData

;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)



notification(10) repeaterHealth(43);

bRepeaterHealth BEHAVIOUR

DEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.3.4.1.;

nRepeaterReset NOTIFICATION

BEHAVIOUR bRepeaterReset;

WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.RepeaterHealthInfo

AND ATTRIBUTE IDS fnRepeaterHealthState aRepeaterHealthState, fnRepeaterHealthText aRepeaterHealthText, fnRepeaterHealthData aRepeaterHealthData

;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) notification(10) repeaterReset(44);

bRepeaterReset BEHAVIOUR


nGroupMapChange NOTIFICATION

BEHAVIOUR bGroupMapChange;

WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) notification(10) groupMapChange(45);

bGroupMapChange BEHAVIOUR


H.2.2 ResourceTypeID managed object class

H.2.2.1 ResourceTypeID formal definition

-- Implementation of this managed object in accordance with the definition contained in -- IEEE Std 802.1F-1993 is a conformance requirement of this standard.

-- NOTE—A single instance of the Resource Type ID managed object exists within the -- Repeater managed object class. The managed object itself is contained in -- IEEE Std. 802.1F-1993; therefore, only the name binding appears in this standard.

nbResourceTypeId NAME BINDING

SUBORDINATE OBJECT CLASS “IEEE802.1F”:oResourceTypeID;

NAMED BY SUPERIOR OBJECT CLASSoRepeater AND SUBCLASSES;

WITH ATTRIBUTE “IEEE802.1F”:aResourceTypeIDName;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) nameBinding(6) resourceTypeID(9);



H.2.3 Group managed object class

H.2.3.1 Group formal definition

oGroup MANAGED OBJECT CLASSDERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2


pGroupBasicControl PACKAGEATTRIBUTES aGroupID GET,

aGroupPortCapacity GET,aPortMap GET;

NOTIFICATIONS nPortMapChange;;

;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

managedObjectClass(3) groupObjectClass(2);

nbGroupName NAME BINDINGSUBORDINATE OBJECT CLASS oGroup;NAMED BY SUPERIOR OBJECT CLASS

oRepeater AND SUBCLASSES;WITH ATTRIBUTE aGroupID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

nameBinding(6) groupName(10);

H.2.3.2 Group attributes

aGroupID ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bGroupID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) groupID(20);

bGroupID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.5.1.1.;

aGroupPortCapacity ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bGroupPortCapacity;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) groupPortCapacity(21);

bGroupPortCapacity BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.5.1.2.;

aPortMap ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

BitString;MATCHES FOR EQUALITY;BEHAVIOUR bPortMap;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) attribute(7) portMap(22);

bPortMap BEHAVIOUR


H.2.3.3 Group notifications

nPortMapChange NOTIFICATION

BEHAVIOUR bPortMapChange;

WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) notification(10) portMapChange(46);

bPortMapChange BEHAVIOUR


H.2.4 Port managed object class

H.2.4.1 Port formal definitionoPort MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 1992":top;

CHARACTERIZED BY

pPortBasicControl PACKAGE

ATTRIBUTES aPortID GET,aPortAdminState GET,aAutoPartitionState GET;

ACTIONS acPortAdminControl;

;

;

CONDITIONAL PACKAGES

pPortPerfMonitor PACKAGE

ATTRIBUTES aReadableFrames GET,aReadableOctets GET,aFrameCheckSequenceErrors GET,aAlignmentErrors GET,aFramesTooLong GET,aShortEvents GET,aRunts GET,aCollisions GET,aLateEvents GET,aVeryLongEvents GET,aDataRateMismatches GET,aAutoPartitions GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) package(4) portPerfMonitorPkg(5);

PRESENT IF The Performance Monitor Capability is implemented.;



pPortAddrTracking PACKAGEATTRIBUTES aLastSourceAddress GET,

aSourceAddressChanges GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

repeaterMgt(19) package(4) portAddrTrackPkg(6);PRESENT IF The Address Tracking and Performance Monitor

capabilities are implemented.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

managedObjectClass(3) portObjectClass(3);

nbPortName NAME BINDINGSUBORDINATE OBJECT CLASS oPort;NAMED BY SUPERIOR OBJECT CLASS

oGroup AND SUBCLASSES;WITH ATTRIBUTE aPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

nameBinding(6) portName(11);

H.2.4.2 Port attributes

aPortID ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

OneOfName;BEHAVIOUR bPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) portID(23);

bPortID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.1.;

aPortAdminState ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

PortAdminState;MATCHES FOR EQUALITY;BEHAVIOUR bPortAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) portAdminState(24);

bPortAdminState BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.2.;

aAutoPartitionState ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

AutoPartitionState;MATCHES FOR EQUALITY;BEHAVIOUR bAutoPartition;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) autoPartitionState(25);

bAutoPartition BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.3.;

aReadableFrames ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bReadableFrames;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19) attribute(7) readableFrames(26);

bReadableFrames BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.4.


aReadableOctets ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bReadableOctets;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) readableOctets(27);

bReadableOctets BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.5.

NOTE—The approximate minimum time between counter rollovers is 58 min.;

aFrameCheckSequenceErrors ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bFCSErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)


bFCSErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.6.


aAlignmentErrors ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bAlignmentErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)


bAlignmentErrors BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.7.


aFramesTooLong ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bFramesTooLong;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) framesTooLong(30);

bFramesTooLong BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.8.


aShortEvents ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bShortEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) shortEvents(31);



bShortEvents BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.9.

NOTE—The approximate minimum time between counter rollovers is 16 h;

aRunts ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bRunts;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) runts(32);

bRunts BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.10.


aCollisions ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) collisions(33);

bCollisions BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.11.


aLateEvents ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bLateEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) lateEvents(34);

bLateEvents BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.12.


aVeryLongEvents ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bVeryLongEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) veryLongEvents(35);

bVeryLongEvents BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.13.;


aDataRateMismatches ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bDataRateMismatches;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) dataRateMismatches(36);

bDataRateMismatches BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.14.;



aAutoPartitions ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bAutoPartitions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) autoPartitions(37);

bAutoPartitions BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.15.;

aLastSourceAddress ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802CommonDefinitions.MACAddress;MATCHES FOR EQUALITY;BEHAVIOUR bLastSourceAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) lastSourceAddress(38);

bLastSourceAddress BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.16.;

aSourceAddressChanges ATTRIBUTEDERIVED FROM aRMCounter;BEHAVIOUR bSourceAddressChanges;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) sourceAddressChanges(39);

bSourceAddressChanges BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.1.17.


H.2.4.3 Port actions

acPortAdminControl ACTIONBEHAVIOUR bPortAdminControl;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

PortAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

action(9) portAdminControl(42);

bPortAdminControl BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 19.2.6.2.1.;

H.2.5 Common Attributes Template

aRMCounter ATTRIBUTEDERIVED FROM "ISO/IEC 10165-2":GenericSettableCounterBEHAVIOUR bRMCounterREGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) rmCounter(12);

bRMCounter BEHAVIOURDEFINED AS The internal event that is counted is specified by each calling attribute.

The maximum value is 4 294 967 295 (i.e., wraps at 32 bits).The estimated minimum wrap time is called out in a note included in the



behaviour of each calling attribute.The counter that this is derived from initializes to zero. Initialization to zero is not a requirement of this standard, this standard only supports a GET operation of this counter.;

H.3 GDMO specification for MAU Management Objects


This clause formally defines the MAU Management Objects using the templates specified in ISO/IEC10165-4: 1992.

Each attribute definition in this clause references directly by means of the WITH ATTRIBUTE SYNTAXconstruct or indirectly by means of the DERIVED FROM construct an ASN.1 type or subtype that definesthe attribute’s type and range. Those ASN.1 types and subtypes defined exclusively for CSMA/CD Manage-ment are included in H.4.

H.3.1 MAU Managed Object Class

H.3.1.1 MAU formal definition

oMAU MANAGED OBJECT CLASSDERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;CHARACTERIZED BY

pMAUBasic PACKAGEATTRIBUTES aMAUID GET,

aMAUType GET,aMediaAvailable GET,aJabber GET,aMAUAdminControl GET;

NOTIFICATIONS nJabber;;

;CONDITIONAL PACKAGES

pMAUControl PACKAGEACTIONS acResetMAU,

acMAUAdminState;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) package(4) mau-

ControlPkg(202);PRESENT IF The pMAUControl package is implemented.;

pMediaLossTracking PACKAGEATTRIBUTES aLoseMediaCounter GET;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) package(4) media-

LossTrackingPkg(203);PRESENT IF MAU TypeValue = AUI or if the pMediaLossTracking package is

implemented.;

pBroadbandDTEMAU PACKAGEATTRIBUTES aBbMAUXmitRcvSplitType GET,

aBroadbandFrequencies GET;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) package(4) broad-

bandMAUPkg(204);



PRESENT IF The MAU is of type 10BROAD36.;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) managedObjectClass(3) mauObjectClass(201);

nbRepeaterMAUName NAME BINDINGSUBORDINATE OBJECT CLASS oMAU;NAMED BY SUPERIOR OBJECT CLASS (of oRepeaterPort)

oPort AND SUBCLASSES;--1.2.840.10006.19.3.3

WITH ATTRIBUTE aMAUID;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) nameBinding(6)

repeaterName(205);

nbDTEMAUName NAME BINDINGSUBORDINATE OBJECT CLASS oMAU;NAMED BY SUPERIOR OBJECT CLASS (of oDTEPort)

oDTECSMACDInterface AND SUBCLASSES(1.2.840.10006.5.3.X;

WITH ATTRIBUTE aMAUID;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) nameBinding(6)

dteName(206);

H.3.1.2 MAU attributesaMAUID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;

MATCHES FOR EQUALITY;BEHAVIOUR bMAUID;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7)

mauID(207);

bMAUID BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.1.;

aMAUType ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

TypeValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMAUType;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7)

mauType(208);

bMAUType BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.2.;

aMediaAvailable ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

MediaAvailState;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMediaAvailable;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7)

mauMediaAvailable(209);

bMediaAvailable BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.3.;



aLoseMediaCounter ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

aRMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bLoseMediaCounter;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7) mauLoseMediaCounter(201);

bLoseMediaCounter BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.4.;

aJabber ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

Jabber;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bJabberAttribute;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7) jabber(211);

bJabberAttribute BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.5.;

aMAUAdminState ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

AdminState;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMAUAdminState;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7) mauAdminState(212);

bMAUAdminState BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.6.;

aBbMAUXmitRcvSplitType ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

BbandXmitRcvSplitType;MATCHES FOR EQUALITY;BEHAVIOUR bBbMAUXmitRcvSplitType;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7) bBandSplitType(213);

bBbMAUXmitRcvSplitType BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.7.;

aBroadbandFrequencies ATTRIBUTEWITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.

BbandFrequency;MATCHES FOR EQUALITY;BEHAVIOUR bBroadbandFrequencies;

REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) attribute(7) bBandFrequencies(214);



bBroadbandFrequencies BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.1.8.;

H.3.1.3 MAU actionsacResetMAU ACTION

BEHAVIOUR bResetMAU;MODE CONFIRMED;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) action(9)

resetMAU(215);

bResetMAU BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.2.1.;

acMAUAdminControl ACTIONBEHAVIOUR bMAUAdminControl;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

AdminState;MODE CONFIRMED;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) action(9)

mauAdminCtrl(216);

bMAUAdminControl BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.2.2.2.;

H.3.1.4 MAU notificationsnJabber NOTIFICATION

BEHAVIOUR bJabberNotification;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

Jabber;;REGISTERED AS iso(1) std(0) iso8802(8802) csma(3) mauMgt(20) notification(10)

jabber(217);

bJabberNotification BEHAVIOURDEFINED AS See “BEHAVIOUR DEFINED AS” in 20.2.3.4.1.;

H.4 GDMO and ASN.1 definitions for management

H.4.1 Common Attributes Template

aRMCounter ATTRIBUTEDERIVED FROM “ISO/IEC 10165-5”:genericWrappingCounter;BEHAVIOUR bRMCounter;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) repeaterMgt(19)

attribute(7) rmCounter(12);

bRMCounter BEHAVIOUR

DEFINED AS Wraps at 32 bits, that is, this counter reaches its maximum value at 232 –1 (decimal 4 294 967 295) and then rolls over to zero on the next increment. The counter from which this is derived initializes to zero. Initialization to zero is not a requirement of this standard;



aLMCounter ATTRIBUTEDERIVED FROM “ISO/IEC 10165-5”:genericWrappingCounter;BEHAVIOUR bRMCounter;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmalayermgt(5)

attribute(7) lmCounter(150);

H.4.2 ASN.1 module

This ASN.1 module defines the ASN.1 types and subtypes that are referred to immediately after the WITHATTRIBUTE SYNTAX construct in this document’s uses of the attribute template defined in ISO/IEC10165-4 : 1992.

IEEE802Dot3-MgmtAttributeModule iso(1) member-body(2) us(840) 802dot3(10006) global(1) asn1Module(2) commonDefinitions(X) version(X) DEFINITIONS IMPLICIT TAGS::= BEGIN

EXPORTS --everythingIMPORTS --implicitly imports ISO 8824

MACAddress FROM IEEE802CommonDefinitionsiso(1) member-body(2) us(840) ieee802-1partf(x) asn1Module(2) commonDefinitions(0) version1(0);

AdminState::= ENUMERATED other (1), --undefinedunknown (2), --initializing, true state not yet knownoperational (3), --powered and connectedstandby (4), --inactive but onshutdown (5) --similar to power down

AttemptArray::= SEQUENCE OF aLMCounter--array [1..attempt limit – 1]

AutoPartitionState::= ENUMERATED autoPartitioned (1),notAutoPartitioned (2)

BbandFrequency::= SEQUENCE xmitCarrierFrequency [1] INTEGER , --Freq. in MHz times 4, (250 kHz resolution)translationFrequency [2] INTEGER --Freq. in MHz times 4, (250 kHz resolution)

BbandXmitRcvSplitType::= ENUMERATED other (1), --undefinedsingle (2), --single-cable systemdual (3) --dual-cable system, offset normally zero

BitString ::= BIT STRING (SIZE (1..1024))

Jabber::= SEQUENCE jabberFlag [1] JabberFlag,jabberCounter [2] JabberCounter



JabberFlag::= ENUMERATED other (1), --undefinedunknown (2), --initializing, true state not yet knownnormal (3), --state is true or normalfault (4) --state is false, fault or abnormal

JabberCounter::= INTEGER (0..232 –1)

MediaAvailState::= ENUMERATED other (1), --undefinedunknown (2), --initializing, true state not yet knownavailable (3), --link or light normal, loopback normalnot available (4), --link loss or low light, no loopbackremote fault (5), --remote fault, applies only to 10BASE-FBinvalid signal (6) --invalid signal, applies only to 10BASE-FB

MulticastAddressList::= SEQUENCE OF MACAddress

OneOfName ::= INTEGER (1..1024)

PortAdminState::= ENUMERATED disabled (1),enabled (2)

RepeaterHealthData ::= OCTET STRING (SIZE (0..255))

RepeaterHealthInfo::= SEQUENCE repeaterHealthState [1] RepeaterHealthState,repeaterHealthText [2] RepeaterHealthText OPTIONAL,repeaterHealthData [3] RepeaterHealthData OPTIONAL

RepeaterHealthState::= ENUMERATED other (1), --undefined or unknownok (2), --no known failuresrepeaterFailure (3), --known to have a repeater-related failuregroupFailure (4), --known to have a group-related failureportFailure (5), --known to have a port-related failuregeneralFailure (6) --has a failure condition, unspecified type

RepeaterHealthText ::= PrintableString (SIZE (0..255))

TrueFalse ::= BOOLEAN

TypeValue::= ENUMERATED global (0), --undefinedother (1), --undefinedunknown (2), --initializing, true state not yet knownAUI (7), --no internal MAU, view from AUI10BASE5 (8), --Thick coaxial cable MAU as specified in Clause 8FOIRL (9), --FOIRL MAU as specified in 9.910BASE2 (10), --Thin coaxial cable MAU as specified in Clause 10



10BROAD36 (11), --Broadband DTE MAU as specified in Clause 1110BASE-T (14), --UTP MAU as specified in Clause 1410BASE-FP (16), --Passive fiber MAU, specified in Clause 1610BASE-FB (17), --Synchronous fiber MAU, specified in Clause 1710BASE-FL (18) --Asynchronous fiber MAU, specified in Clause 18

END



NOTE—The remaining annexes in the standard are numbered in correspondence to their associated clauses; e.g.,Annexes 22A, 22B, and 22C correspond to Clause 22.

Annex 22A

(informative)

MII output delay, setup, and hold time budget

22A.1 System model

The discussion of signal timing characteristics that follows will refer to the system model depicted inFigure 22A–1, Figure 22A–2, and Figure 22A–3. This system model can be applied to each of the threeapplication environments defined in 22.2.1.

Figure 22A–1 depicts a simple system model in which the MII is used to interconnect two integrated circuitson the same circuit assembly. In this model the Reconciliation sublayer comprises one integrated circuit, andthe PHY comprises the other. A Reconciliation sublayer or a PHY may actually be composed of several sep-arate integrated circuits. The system model in Figure 22A–1 includes two unidirectional signal transmissionpaths, one from the Reconciliation sublayer to the PHY and one from the PHY to the Reconciliation sub-layer. The path from the Reconciliation sublayer to the PHY is separated into two sections, labeled A1 andB1. The path from the PHY to the Reconciliation sublayer is separated into two sections, labeled C1 and D1.

Figure 22A–2 depicts a system model for the case where the MII is used to interconnect two circuit assem-blies. The circuit assemblies may be physically connected in a motherboard/daughterboard arrangement, orthey may be physically connected with the cable defined in 22.4.5 and the line interface connector defined in22.6. The system model in Figure 22A–2 includes two unidirectional signal transmission paths, one from theReconciliation sublayer to the PHY and one from the PHY to the Reconciliation sublayer. The path from theReconciliation sublayer to the PHY is separated into two sections, labeled A2 and B2. The path from thePHY to the Reconciliation sublayer is separated into two sections, labeled C2 and D2.

Figure 22A–3 depicts a system model in which the MII is used to interconnect both integrated circuits andcircuit assemblies. This system model allows for separate signal transmission paths to exist between theReconciliation sublayer and a local PHY(L), and between the Reconciliation sublayer and a remote PHY(R).The unidirectional paths between the Reconciliation sublayer and the PHY(L) are composed of sections A1,B1, C1, and D1. The unidirectional paths between the Reconciliation sublayer and the remote PHY(R) arecomposed of sections A2, B2, C2, and D2.

ReconciliationPHY(L)

A1

D1 C1

B1

sublayer

Figure 22A–1—Model for integrated circuit to integrated circuit connection



Each of these system models assumes a set of common timing and electrical characteristics that shall be met atthe input and output ports of the Reconciliation sublayer and PHY devices. The characteristics of the signaltransmission paths are identified for each of the sections A1, B1, C1, D1, A2, B2, C2, and D2.

22A.2 Signal transmission path characteristics

The signal transmission path characteristics are specified for each of the path sections defined in 22A.1. Thecharacteristics for these sections are specified so as to allow sections A1, B1, C1, and D1 to be implementedin the form of printed circuit board traces, while sections A2, B2, C2, and D2 may be implemented with acombination of printed circuit board traces and wire conductors in a cable assembly.

The signal transmission path characteristics are stated in terms of their maximum delay and their character-istic impedance. These values are summarized in Table 22A–1.

PHY(R)

D2

B2

C2

Reconciliation

sublayer

Figure 22A–2—Model for circuit assembly to circuit assembly connection

A2

PHY(L) PHY(R)

A1

D1

D2

A2

C1

B1

B2

C2

Reconciliation

sublayer

Figure 22A–3—Combined model



The driver characteristics specified in 22.4.3, the receiver characteristics specified in 22.4.4, and the signaltransmission path characteristics specified in Table 22A–1 can be applied to the system models shown inFigure 22A–1 or Figure 22A–2. The combination of loads presented in Figure 22A–3 cannot be adequatelydriven by an output buffer that meets the driver characteristics specified in 22.4.3 while being sampled by aninput buffer that meets the receiver characteristics specified in 22.4.4.

To address the system model depicted in Figure 22A–3, it is permissible to incorporate an additional stage ofbuffering into path sections A1, A2, D1, and D2, provided that the resulting maximum delay characteristicfor those path sections does not exceed the value stated in Table 22A–1. The delay characteristic for trans-mission path sections A2 and D2 includes an allowance for the delay that results from the presence of alumped capacitive load at the end of the path. For a transmission path section with a characteristic imped-ance Zo, with a lumped capacitive load CL, this delay is nominally ZoCL. In the case of a maximum trans-mission path section impedance of 78 Ω with a lumped load of 8 pF, the nominal delay is 0.6 ns. Thus theallowable delay for a buffer inserted into transmission path section A2 or D2 is 4.4 ns.

22A.3 Budget calculation

A recommended timing budget is shown in Table 22A–2. This budget assumes that the combined systemmodel shown in Figure 22A–3 represents a worst case.

Table 22A–1—Signal transmission path characteristics

Section Maximum delay (ns) Impedance (Ω)

A1, D1 5 68 ± 15%

B1, C1 2.5 68 ± 15%

A2, D2 5 68 ± 10%

B2, C2 2.5 68 ± 10%

Table 22A–2—Round-trip delay budget

Description Incremental

delay (ns)Cumulative delay (ns)

TX_CLK output at PHY(R) 0.0 0.0

Transmission path section C2 2.5 2.5

Transmission path section D2 5.0 7.5

clock to output in Reconciliation sublayer 15.0 22.5

Transmission path section A2 5.0 27.5

Transmission path section B2 2.5 30.0

Setup time at PHY(R) 10.0 40.0



Annex 22B

(informative)

MII driver ac characteristics

22B.1 Implications of CMOS ASIC processes

For MII drivers that drive rail to rail, such as those commonly used in CMOS ASICs (complimentary metaloxide semiconductor application-specific integrated circuits), the ac characteristic performance requirementsof 22.4.3.2 can be met if the Voh vs. Ioh and Vol vs. Iol dc characteristics of the driver stay within theunshaded areas of Figure 22B–1.

The variation in output resistance of a field effect transistor (FET) due to variations in supply voltage, tem-perature, and process may require that a resistance be placed in series with the output of the FETs to meetthis specification. The series resistance can be part of the driver circuit, or external to the driver. If the seriesresistance is not part of the driver circuit, the driver vendor shall specify the value of series resistancerequired to meet the specification. A series resistor used to meet this specification is conceptually part of thedriver regardless of whether it is physically internal or external to the driver.

The propagation delay of the path between the driver and an external series resistor used to meet the specifi-cation shall not exceed 10% of the 10–90% rise/fall time of the driver.

Vol

Ioh

V1

I1

V2

I2

V3

I3

V4

I4Roh(min)

Rol(min)

Voh

Iol

Vcc

Figure 22B–1—Driver output V–I curve



22B.2 Ro(min) and V, I values for operation from 5 V ± 10% supply

Referring to Figure 22B–1, Roh(min) and Rol(min) both equal 40 Ω, and the values for the V-I points on thecurve are given in Table 22B–1 for MII drivers that drive rail to rail from a +5 V ± 10% power supply.

22B.3 Ro(min) and V, I values for operation from 3.3 ± 0.3 V supply

Referring to Figure 22B–1, Roh(min) and Rol(min) both equal 33 Ω, and the values for the V–I points on thecurve are given in Table 22B–2 for MII drivers that drive rail to rail from a +3.3 ± 0.3 V power supply.

Table 22B–1—Values for driver output V-I curve (5 V supply)

V–I point I (mA) V (V)

I1, V1 –20 1.10

I2, V2 –4 2.4

I3, V3 4 0.40

I4, V4 43 3.05

Table 22B–2—Values for driver output V-I curve (3.3 V supply)

V-I point I (mA) V (V)

I1,V1 –20 1.10

I2,V2 –4 2.4

I3,V3 4 0.40

I4,V4 26 2.10



Annex 22C

(informative)

Measurement techniques for MII signal timing characteristics

22C.1 Measuring timing characteristics of source terminated signals

The measurement of timing relationships between MII signals at the MII connector is complicated by theuse of driver output impedance to control transmission line reflections on point-to-point transmission pathspassing through the connector. The voltage waveforms on point-to-point transmission paths can be differentat the MII connector and at the end of the paths. A clean transition (or step) from one logic state to the otherat the end of a point to point path can appear as two half-steps at the MII connector.

To eliminate ambiguity as to where on a two half-step state transition to measure timing, all timing measure-ments on point-to-point transmission paths will be at the end of the path. In some cases, an end of path mustbe artificially created.

22C.2 Measuring timing characteristics of transmit signals at the MII

The timing of TX_EN, TX_ER, and TXD<3:0> relative to TX_CLK at the MII connector is measured asfollows.

Use the time base for TX_CLK as a timing reference. Break the TX_CLK path at the MII connector, forcingthe TX_CLK point-to-point transmission path to end at the connector. Measure when the rising edge ofTX_CLK passes through Vih(min) at the MII connector. Call this time Tclk. Reconnect the TX_CLK path atthe MII connector and break the paths of TX_EN, TX_ER, and TXD<3:0> at the MII connector, forcing thepaths to end at the connector. Measure when TX_EN, TX_ER, and TXD<3:0> exit the switching region atthe MII connector. Call these times Ten, Ter, and T<3:0>, respectively.

The timing relationships at the MII connector for TX_EN, TX_ER, and TXD<3:0> relative to TX_CLK aremet if (Ten – Tclk), (Ter – Tclk), (T3 – Tclk), (T2 – Tclk), (T1 – Tclk), and (T0 – Tclk), respectively, meet the tim-ing relationships specified in 22.3.1.

22C.3 Measuring timing characteristics of receive signals at the MII

The timing of RX_DV, RX_ER, and RXD<3:0> relative to RX_CLK at the MII connector is measured asfollows.

Break the paths of RX_CLK, RX_DV, RX_ER, and RXD<3:0> at the MII connector, forcing the paths toend at the connector. Measure when RX_DV, RX_ER, and RXD<3:0> exit the switching region at the MIIconnector relative to when the rising edge of RX_CLK passes through Vil(max). Also measure when RX_DV,RX_ER, and RXD<3:0> reenter the switching region relative to when the rising edge of RX_CLK passesthrough Vih(min).

The timing relationships at the MII connector for RX_DV, RX_ER, and RXD<3:0> relative to RX_CLK aremet if the times measured in the previous step meet the timing relationships specified in 22.3.2.



22C.4 Measuring timing characteristics of MDIO

The MDIO and MDC signal timing characteristics cannot be measured using the techniques defined for thetransmit and receive signals since MDIO and MDC may connect a single station management entity to mul-tiple PHY devices. The MDIO and MDC timing characteristics are measured with a PHY connected to theMII connector. The signal timing characteristics for MDC and MDIO must be met over the range of condi-tions which occur when from one to 32 PHYs are connected to an STA. When 32 PHYs are connected to anSTA, the total capacitance can be as large as 390 pF on MDC, and as large as 470 pF on MDIO.



Annex 23A

(normative)

6T code words

The leftmost ternary symbol of each 6T Code group shown in Table 23A–1 (broken into 23A–1a and23A–1b for pagination) shall be transmitted first. The leftmost nibble of each data octet is the mostsignificant.

Table 23A–1a—100BASE-T4 8B6T code table

Dataoctet 6T code group



Dataoctet

6T code group

00 + - 0 0 + - 20 0 0 - + + - 40 + 0 + 0 0 - 60 0 - 0 + + 0

01 0 + - + - 0 21 - - + 0 0 + 41 + + 0 0 - 0 61 0 0 - + 0 +

02 + - 0 + - 0 22 + + - 0 + - 42 + 0 + 0 - 0 62 0 - 0 + 0 +

03 - 0 + + - 0 23 + + - 0 - + 43 0 + + 0 - 0 63 - 0 0 + 0 +

04 - 0 + 0 + - 24 0 0 + 0 - + 44 0 + + 0 0 - 64 - 0 0 + + 0

05 0 + - - 0 + 25 0 0 + 0 + - 45 + + 0 - 0 0 65 0 0 - 0 + +

06 + - 0 - 0 + 26 0 0 - 0 0 + 46 + 0 + - 0 0 66 0 - 0 0 + +

07 - 0 + - 0 + 27 - - + + + - 47 0 + + - 0 0 67 - 0 0 0 + +

08 - + 0 0 + - 28 - 0 - + + 0 48 0 0 0 + 0 0 68 - + - + + 0

09 0 - + + - 0 29 - - 0 + 0 + 49 0 0 0 - + + 69 - - + + 0 +

0A - + 0 + - 0 2A - 0 - + 0 + 4A 0 0 0 + - + 6A - + - + 0 +

0B + 0 - + - 0 2B 0 - - + 0 + 4B 0 0 0 + + - 6B + - - + 0 +

0C + 0 - 0 + - 2C 0 - - + + 0 4C 0 0 0 - + 0 6C + - - + + 0

0D 0 - + - 0 + 2D - - 0 0 + + 4D 0 0 0 - 0 + 6D - - + 0 + +

0E - + 0 - 0 + 2E - 0 - 0 + + 4E 0 0 0 + - 0 6E - + - 0 + +

0F + 0 - - 0 + 2F 0 - - 0 + + 4F 0 0 0 + 0 - 6F + - - 0 + +

10 + 0 + - - 0 30 + - 0 0 - + 50 + 0 + - - + 70 - + + 0 0 0

11 + + 0 - 0 - 31 0 + - - + 0 51 + + 0 - + - 71 + - + 0 0 0

12 + 0 + - 0 - 32 + - 0 - + 0 52 + 0 + - + - 72 + + - 0 0 0

13 0 + + - 0 - 33 - 0 + - + 0 53 0 + + - + - 73 0 0 + 0 0 0

14 0 + + - - 0 34 - 0 + 0 - + 54 0 + + - - + 74 - 0 + 0 0 0

15 + + 0 0 - - 35 0 + - + 0 - 55 + + 0 + - - 75 0 - + 0 0 0

16 + 0 + 0 - - 36 + - 0 + 0 - 56 + 0 + + - - 76 + 0 - 0 0 0

17 0 + + 0 - - 37 - 0 + + 0 - 57 0 + + + - - 77 0 + - 0 0 0

18 0 + - 0 + - 38 - + 0 0 - + 58 + + + 0 - - 78 0 - - + + +

19 0 + - 0 - + 39 0 - + - + 0 59 + + + - 0 - 79 - 0 - + + +

1A 0 + - + + - 3A - + 0 - + 0 5A + + + - - 0 7A - - 0 + + +

1B 0 + - 0 0 + 3B + 0 - - + 0 5B + + 0 - - 0 7B - - 0 + + 0

1C 0 - + 0 0 + 3C + 0 - 0 - + 5C + + 0 - - + 7C + + - 0 0 -

1D 0 - + + + - 3D 0 - + + 0 - 5D + + 0 0 0 - 7D 0 0 + 0 0 -

1E 0 - + 0 - + 3E - + 0 + 0 - 5E - - + + + 0 7E + + - - - +

1F 0 - + 0 + - 3F + 0 - + 0 - 5F 0 0 - + + 0 7F 0 0 + - - +



Table 23A–1b—100BASE-T4 8B6T code table




Dataoctet

6T code group

80 + - + 0 0 - A0 0 - 0 + + - C0 + - + 0 + - E0 + - 0 + + -

81 + + - 0 - 0 A1 0 0 - + - + C1 + + - + - 0 E1 0 + - + - +

82 + - + 0 - 0 A2 0 - 0 + - + C2 + - + + - 0 E2 + - 0 + - +

83 - + + 0 - 0 A3 - 0 0 + - + C3 - + + + - 0 E3 - 0 + + - +

84 - + + 0 0 - A4 - 0 0 + + - C4 - + + 0 + - E4 - 0 + + + -

85 + + - - 0 0 A5 0 0 - - + + C5 + + - - 0 + E5 0 + - - + +

86 + - + - 0 0 A6 0 - 0 - + + C6 + - + - 0 + E6 + - 0 - + +

87 - + + - 0 0 A7 - 0 0 - + + C7 - + + - 0 + E7 - 0 + - + +

88 0 + 0 0 0 - A8 - + - + + - C8 0 + 0 0 + - E8 - + 0 + + -

89 0 0 + 0 - 0 A9 - - + + - + C9 0 0 + + - 0 E9 0 - + + - +

8A 0 + 0 0 - 0 AA - + - + - + CA 0 + 0 + - 0 EA - + 0 + - +

8B + 0 0 0 - 0 AB + - - + - + CB + 0 0 + - 0 EB + 0 - + - +

8C + 0 0 0 0 - AC + - - + + - CC + 0 0 0 + - EC + 0 - + + -

8D 0 0 + - 0 0 AD - - + - + + CD 0 0 + - 0 + ED 0 - + - + +

8E 0 + 0 - 0 0 AE - + - - + + CE 0 + 0 - 0 + EE - + 0 - + +

8F + 0 0 - 0 0 AF + - - - + + CF + 0 0 - 0 + EF + 0 - - + +

90 + - + - - + B0 0 - 0 0 0 + D0 + - + 0 - + F0 + - 0 0 0 +

91 + + - - + - B1 0 0 - 0 + 0 D1 + + - - + 0 F1 0 + - 0 + 0

92 + - + - + - B2 0 - 0 0 + 0 D2 + - + - + 0 F2 + - 0 0 + 0

93 - + + - + - B3 - 0 0 0 + 0 D3 - + + - + 0 F3 - 0 + 0 + 0

94 - + + - - + B4 - 0 0 0 0 + D4 - + + 0 - + F4 - 0 + 0 0 +

95 + + - + - - B5 0 0 - + 0 0 D5 + + - + 0 - F5 0 + - + 0 0

96 + - + + - - B6 0 - 0 + 0 0 D6 + - + + 0 - F6 + - 0 + 0 0

97 - + + + - - B7 - 0 0 + 0 0 D7 - + + + 0 - F7 - 0 + + 0 0

98 0 + 0 - - + B8 - + - 0 0 + D8 0 + 0 0 - + F8 - + 0 0 0 +

99 0 0 + - + - B9 - - + 0 + 0 D9 0 0 + - + 0 F9 0 - + 0 + 0

9A 0 + 0 - + - BA - + - 0 + 0 DA 0 + 0 - + 0 FA - + 0 0 + 0

9B + 0 0 - + - BB + - - 0 + 0 DB + 0 0 - + 0 FB + 0 - 0 + 0

9C + 0 0 - - + BC + - - 0 0 + DC + 0 0 0 - + FC + 0 - 0 0 +

9D 0 0 + + - - BD - - + + 0 0 DD 0 0 + + 0 - FD 0 - + + 0 0

9E 0 + 0 + - - BE - + - + 0 0 DE 0 + 0 + 0 - FE - + 0 + 0 0

9F + 0 0 + - - BF + - - + 0 0 DF + 0 0 + 0 - FF + 0 - + 0 0



Annex 23B

(informative)

Noise budget

Worst-case values for noise effects in the 100BASE-T4 system are as shown in Tables 23B–1 and 23B–2.

Table 23B–1—Carrier presence analysis

Received signal peak amplitude (min.) 792 mVp

NEXT noise 325 mVp

Table 23B–2—Far-end signal analysis

Received signal peak amplitude (min.) 796 mVp

Baseline wander 14 mVp

ISI 80 mVp

Reflections 60 mVp

FEXT noise 87 mVp



Annex 23C

(informative)

Use of cabling systems with a nominal differential characteristic impedance of 120 Ω

The 100BASE-T4 standard specifies only the use of 100 Ω link segments for conformance. Since ISO/IEC11801: 1995 also recognizes 120 Ω cabling, this informative annex specifies the conditions for using cablingsystems with a nominal characteristic impedance of 120 Ω by 100BASE-T4 conformant stations.

The use of cables with a characteristic impedance outside the range specified in 23.6 will generally increasethe mismatching effects in the link components, inducing additional noise in the received signals.

In particular, the use of a homogeneous link segment having a characteristic impedance of 120 Ω ±15 Ω overthe frequency band 1 to 16 MHz may add up to 1.4% of additional noise to the signals at the input of thereceivers (worst-case short-length link segment).

Therefore, in order to keep the overall noise (MDFEXT + reflections) at the same value as for a 100 Ω linksegment when using a 120 Ω link segment, the minimum ELFEXT loss requirement for the cable must beincreased by 2 dB (i.e., from 23 dB to 25 dB at 12.5 MHz, see 23.6.3.2). Accordingly, the MDFEXT noiserequirement shall be decreased from 87 mV peak to 69 mV peak. In practice, this means that cables ratedcategory 4 or higher, as specified in ISO/IEC 11801: 1995, are required when 120 Ω cables are used with100BASE-T4 compliant PMDs.

NOTE 1—The use of 100 Ω cords at end points in conjunction with 120 Ω premises cabling may be tolerated providedthat all the components of the link are of Category 5, as defined in ISO/IEC 11801: 1995.

NOTE 2—The use of 100 Ω cords at any intermediate cross-connect points on 120 Ω links as well as the use of 120 Ωcords in conjunction with 100 Ω premises cabling is not allowed since it would result in worst-case jitter greater thanthat allowed in this standard.

CAUTION—Users of this annex are further advised to check with the manufacturer of the particular 100BASE-T4 cou-plers they intend to use with a 120 Ω link to see whether those couplers can operate correctly on cables with Zc as highas 120 Ω ± 15 Ω .



Annex 27A

(normative)

Repeater delay consistency requirements

Proper operation of the network requires that repeaters do not cause the Inter-Packet Gap (IPG) to disappearby propagating the end of any carrier event to different output ports with greatly different delay times. Max-imum port-to-port delays have been assigned as absolute delays to meet requirements for detection of colli-sion within a slot time and limiting the length of collision fragments to less than minimum frame size. Toavoid specification of minimum input-to-output propagation time as absolute values that reduce implementa-tion flexibility, these delays are instead implied by imposing a triangular delay inequality relationship.

Consider three ports A, B, C. Using the notation SOP(xy) to mean the start-of-packet delay for an input atport x to resulting output on port y, repeaters shall achieve this relationship for all groups of three portswithin a repeater set:

SOP(AC) < SOP(AB) + SOP(BC)

Following a frame transmitted by node A that propagates to nodes B and C, this constraint ensures that nodeB cannot complete an IPG timer and initiate a transmission that arrives at node C before node C has alsoadvanced its own IPG timer sufficiently that a pending frame can contend for access to the network.

There is a second delay consistency requirement, one that relates to jam propagation by repeaters. Using anotation similar to that above, SOJ(xy) stands for the start-of-jam propagation delay from port x to port yand EOJ(xy) for the end-of-jam delay between same two ports.

To ensure proper detection of collisions and avoid generation of fragments that exceed minimum frame size,maximum values have been imposed on SOJ and EOJ delays through repeaters. No specific minima havebeen specified as all delays less than the maxima meet the collision detection and fragment length criteria.To prevent the jam pattern from shrinking excessively as it propagates through repeaters, repeaters shallmeet this relationship between all pairs of ports:

EOJ(AB) >= SOJ(AB) – 4 bit times



Annex 28A

(normative)

Selector Field definitions

The Selector Field, S[4:0] in the Link Code Word, shall be used to identify the type of message being sent byAuto-Negotiation. The following table identifies the types of messages that may be sent. As new messagesare developed, this table will be updated accordingly.

The Selector Field uses a 5-bit binary encoding, which allows 32 messages to be defined. All unspecifiedcombinations are reserved. Reserved combinations shall not be transmitted.

Table 28A–1—Selector Field value mappings

S4 S3 S2 S1 S0 Selector description

0 0 0 0 0 Reserved for future Auto-Negotiation development

0 0 0 0 1 IEEE Std 802.3

0 0 0 1 0 IEEE Std 802.9 ISLAN-16T

1 1 1 1 1 Reserved for future Auto-Negotiation development



Annex 28B

(normative)

IEEE 802.3 Selector Base Page definition

This annex provides the Technology Ability Field bit assignments, Priority Resolution table, and Message Pagetransmission conventions relative to the IEEE 802.3 Selector Field value within the base page encoding.

As new IEEE 802.3 LAN technologies are developed, a reserved bit in the Technology Ability field may beassigned to each technology by the standards body.

The new technology will then be inserted into the Priority Resolution hierarchy and made a part of the Auto-Negotiation standard. The relative hierarchy of the existing technologies will not change, thus providingbackward compatibility with existing Auto-Negotiation implementations.

It is important to note that the reserved bits are required to be transmitted as logic zeros. This guarantees thatdevices implemented using the current priority table will be forward compatible with future devices using anupdated priority table.

28B.1 Selector field value

The value of the IEEE 802.3 Selector Field is S[4:0] = 00001.

28B.2 Technology Ability Field bit assignments

The Technology bit field consists of bits D5 through D12 (A0–A7, respectively) in the IEEE 802.3 SelectorBase Page. Table 28B–1 summarizes the bit assignments.

Note that the order of the bits within the Technology Ability Field has no relationship to the relative priorityof the technologies.

Setting Bit A5 or Bit A6 indicates that the DTE has implemented both the optional MAC control sublayerand the PAUSE function as specified in Clause 31 and Annex 31B. This capability is significant only whenthe link is configured for full duplex operation, regardless of data rate and medium. The encoding of Bits A5and A6 is specified in Table 28B–2.

Table 28B–1—Technology Ability Field bit assignments

Bit Technology Minimum cabling requirement

A0 10BASE-T Two-pair category 3

A1 10BASE-T full duplex Two-pair category 3

A2 100BASE-TX Two-pair category 5

A3 100BASE-TX full duplex Two-pair category 5

A4 100BASE-T4 Four-pair category 3

A5 PAUSE operation for full duplex links Not applicable

A6 Asymmetric PAUSE operation for full duplex Links Not applicable

A7 Reserved for future technology



The PAUSE bit indicates that the device is capable of providing the symmetric PAUSE functions as definedin Annex 31B. The ASM_DIR bit indicates that asymmetric PAUSE is supported. The value of the PAUSEbit when the ASM_DIR bit is set indicates the direction the PAUSE frames are supported for flow across thelink. Asymmetric PAUSE configuration results in independent enabling of the PAUSE receive and PAUSEtransmit functions as defined by Annex 31B. See 28B.3 regarding PAUSE configuration resolution.

28B.3 Priority resolution

Since two devices may have multiple abilities in common, a prioritization scheme exists to ensure that thehighest common denominator ability is chosen. The following list shall represent the relative priorities of thetechnologies supported by the IEEE 802.3 Selector Field value, where priorities are listed from highest tolowest.

a) 1000BASE-T full duplexb) 1000BASE-Tc) 100BASE-T2 full duplexd) 100BASE-TX full duplexe) 100BASE-T2f) 100BASE-T4g) 100BASE-TXh) 10BASE-T full duplexi) 10BASE-T

The rationale for this hierarchy is straightforward. 10BASE-T is the lowest common denominator andtherefore has the lowest priority. Full duplex solutions are always higher in priority than their half duplexcounterparts. 1000BASE-T has a higher priority than 100 Mb/s technologies. 100BASE-T2 is ahead of100BASE-TX and 100BASE-T4 because 100BASE-T2 runs across a broader spectrum of copper cablingand can support a wider base of configurations. 100BASE-T4 is ahead of 100BASE-TX because 100BASE-T4 runs across a broader spectrum of copper cabling. The relative order of the technologies specified hereinshall not be changed. As each new technology is added, it shall be inserted into its appropriate place in thelist, shifting technologies of lesser priority lower in priority. If a vendor-specific technology is implemented,the priority of all IEEE 802.3 standard technologies shall be maintained, with the vendor specific technologyinserted at any appropriate priority location.

The use of the PAUSE operation for full duplex links (as indicated by bits A5 and A6) is orthogonal to thenegotiated data rate, medium, or link technology. The setting of these bits indicates the availability of addi-tional DTE capability when full duplex operation is in use. The PAUSE function shall be enabled accordingto Table 28B–3 only if the Highest Common Denominator is a full duplex technology. There is no priorityresolution associated with the PAUSE operation.

Table 28B–2—Pause encoding

PAUSE (A5) ASM_DIR (A6) Capability

0 0 No PAUSE

0 1 Asymmetric PAUSE toward link partner

1 0 Symmetric PAUSE

1 1 Both Symmetric PAUSE and Asymmetric PAUSE toward local device



28B.4 Message Page transmission convention

Each series of Unformatted Pages shall be preceded by a Message Page containing a Message Code thatdefines how the following Unformatted Pages will be used.

Next Page message codes should be allocated globally across Selector Field values so that meaningful com-munication is possible between technologies using different Selector Field values.

Table 28B–3—Pause resolution

Local device Link partnerLocal device resolution Link partner resolution

PAUSE ASM_DIR PAUSE ASM_DIR

0 0 Don’t care Don’t care Disable PAUSETransmit and Receive

Disable PAUSETransmit and Receive

0 1 0 Don’t care Disable PAUSETransmit and Receive


0 1 1 0 Disable PAUSETransmit and Receive


0 1 1 1 Enable PAUSE transmitDisable PAUSE receive

Enable PAUSE receiveDisable PAUSE transmit

1 0 0 Don’t care Disable PAUSETransmit and Receive


1 Don’t care 1 Don’t care Enable PAUSETransmit and Receive

Enable PAUSETransmit and Receive

1 1 0 0 Disable PAUSETransmit and Receive


1 1 0 1 Enable PAUSE receiveDisable PAUSE transmit

Enable PAUSE transmitDisable PAUSE receive



Annex 28C

(normative)

Next Page Message Code Field definitions

The Message Code Field of a message page used in Next Page exchange shall be used to identify the mean-ing of a message. The following table identifies the types of messages that may be sent. As new messages aredeveloped, this table will be updated accordingly.

The Message Code Field uses an 11-bit binary encoding that allows 2048 messages to be defined. All Mes-sage Codes not specified shall be reserved for IEEE use or allocation.

28C.1 Message code #0—Auto-Negotiation reserved code 1

This code is reserved for future Auto-Negotiation function enhancements. Devices shall not transmit thiscode.

Table 28C–1—Message code field values

Message Code #

M10

M9

M8

M7

M6

M5

M4

M3

M2

M1

M0 Message Code Description

0 0 0 0 0 0 0 0 0 0 0 0 Reserved for future Auto-Negotiation use

1 0 0 0 0 0 0 0 0 0 0 1 Null Message

2 0 0 0 0 0 0 0 0 0 1 0 One UP with Technology Ability Field follows

3 0 0 0 0 0 0 0 0 0 1 1 Two UPs with Technology Ability Field follow

4 0 0 0 0 0 0 0 0 1 0 0 One UP with Binary coded Remote fault follows

5 0 0 0 0 0 0 0 0 1 0 1 Organizationally Unique Identifier Tagged Message

6 0 0 0 0 0 0 0 0 1 1 0 PHY Identifier Tag Code

7 0 0 0 0 0 0 0 0 1 1 1 100BASE-T2 Technology Message Code. 100BASE-T2 Ability Page to follow using Unformatted Next Page

8 0 0 0 0 0 0 0 1 0 0 0 1000BASE-T Technology Message Code. Two 1000BASE-T Ability Pages to follow using Unformatted Next Pages.

9..... 0 0 0 0 0 0 0 1 0 0 1 Reserved for future Auto-Negotiation use

......2047 1 1 1 1 1 1 1 1 1 1 1 Reserved for future Auto-Negotiation use



28C.2 Message code #1—Null Message code

The Null Message code shall be transmitted during Next Page exchange when the Local Device has no furthermessages to transmit and the Link Partner is still transmitting valid Next Pages. See 28.2.3.4 for more details.

28C.3 Message code #2—Technology Ability extension code 1

This Message Code is reserved for future expansion of the Technology Ability Field and indicates that adefined user code with a specific Technology Ability Field encoding follows.

28C.4 Message code #3—Technology Ability extension code 2

This Message Code is reserved for future expansion of the Technology Ability Field and indicates that twodefined user codes with specific Technology Ability Field encodings follow.

28C.5 Message code #4—Remote fault number code

This Message Code shall be followed by a single user code whose encoding specifies the type of fault thathas occurred. The following user codes are defined:

0: RF TestThis code can be used to test Remote Fault operation.

1: Link Loss2: Jabber3: Parallel Detection Fault

This code may be sent to identify when bit 6.4 is set.

28C.6 Message code #5—Organizationally Unique Identifier (OUI) tag code

The OUI Tagged Message shall consist of a single message code of 0000 0000 0101 followed by four usercodes defined as follows. The first user code shall contain the most significant 11 bits of the OUI (bits23:13) with the most significant bit in bit 10 of the user code. The second user code shall contain the nextmost significant 11 bits of the OUI (bits 12:2) with the most significant bit in bit 10 of the user code. Thethird user code shall contain the remaining least significant 2 bits of the OUI (bits 1:0) with the most signif-icant bit in bit 10 of the user code. Bits 8:0 of the fourth user contain a user-defined user code value that isspecific to the OUI transmitted. The fourth and final user code shall contain a user-defined user code valuethat is specific to the OUI transmitted.

28C.7 Message code #6—PHY identifier tag code

The PHY ID tag code message shall consist of a single message code of 0000 0000 0110 followed by fouruser codes defined as follows. The first user code shall contain the most significant 11 bits of the PHY ID(2.15:5) with the most significant bit in bit 10 of the user code. The second user code shall contain bits 2.4:0to 3.15:10 of the PHY ID with the most significant bit in bit 10 of the user code. The third user code shallcontain bits 3.9:0 of the PHY ID with the most significant bit in bit 10 of the user code. Bit 0 in the third usercode shall contain a user-defined user code value that is specific to the PHY ID transmitted. The fourth andfinal user code shall contain a user-defined user code value that is specific to the PHY ID transmitted.



28C.8 Message code #2047—Auto-Negotiation reserved code 2

This code is reserved for future Auto-Negotiation function enhancements. Devices shall not transmit thiscode.

28C.9 Message code #7—100BASE-T2 technology message code

Clause 32 (100BASE-T2) uses Next Page Message Code 7 to indicate that T2 implementations will followthe transmission of this page [the initial, Message (formatted) Next Page] with two unformatted Next Pageswhich contain information defined in 32.5.4.2.

28C.10 Message Code #8 - 1000BASE-T technology message code

Clause 40 (1000BASE-T) uses Next Page Message Code 8 to indicate that 1000BASE-T implementationswill follow the transmission of this page [the initial, Message (formatted) Next Page] with two unformattedNext Pages that contain information defined in 40.5.1.2.



Annex 28D

(normative)

Description of extensions to Clause 28 and associated annexes

28D.1 Introduction

This annex is to be used to document extensions and modifications to Clause 28 required by IEEE 802.3clauses and other standards that use Auto-Negotiation and that were approved after June 1995. It provides asingle location to define such extensions and modifications without changing the basic contents ofClause 28.

Subclause 28D.2 lists those clauses and standards that require extensions to Clause 28 and provides pointersto the subclauses where those extensions are listed.

28D.2 Extensions to Clause 28

28D.2.1 Extensions required for Clause 31 (full duplex)

Clause 31 (full duplex) requires the use of Auto-Negotiation. Extensions to Clause 28 and associatedannexes required for the correct operation of full duplex are shown in 28D.3.

28D.2.2 Extensions required for Clause 32 (100BASE-T2)

Clause 32 (100BASE-T2) requires the use of Auto-Negotiation. Extensions to Clause 28 required for correctoperation of 100BASE-T2 are shown in 28D.4.

28D.3 Extensions for Clause 31

Full duplex requires the use of bit A5 in the Technology Ability Field of the IEEE 802.3 Selector Base Page.(This bit is also defined as MII bit 4.10.) This bit was previously defined as “reserved for future technology.”

Bit A5 (PAUSE operation for full duplex links) signifies that the DTE has implemented both the optionalMAC Control sublayer and the PAUSE function as specified in Clause 31 and Annex 31B. This capability issignificant only when the link is configured for full duplex operation, regardless of data rate and medium.

Bit Technology Minimum cabling requirement

A5 PAUSE operation for full duplex links Not applicable



28D.4 Extensions for Clause 32 (100BASE-T2)

Clause 32 (100BASE-T2) makes special use of Auto-Negotiation and requires additional MII registers. Thisuse is summarized below. Details are provided in 32.5.

Auto-Negotiation is mandatory for 100BASE-T2 (32.1.3.4).

100BASE-T2 introduces the concept of MASTER and SLAVE to define DTEs and to facilitate the timing oftransmit and receive operations. Auto-Negotiation is used to provide information used to configure MAS-TER/SLAVE status (32.5.4.3).

100BASE-T2 uses unique next page transmit and receive registers (MII Registers 8, 9 and 10) in conjunc-tions with Auto-Negotiation. These registers are in addition to Registers 0–7 as defined in 28.2.4 (32.5.2).

100BASE-T2 use of Auto-Negotiation generates information which is stored in configuration and status bitsdefined for the MASTER-SLAVE Control register (MII Register 9) and the MASTER-SLAVE Status regis-ter (MII Register 10).

100BASE-T2 requires an ordered exchange of next page messages (32.5.1).

100BASE-T2 parameters are configured based on information provided by the ordered exchange of nextpage messages.

100BASE-T2 adds new message codes to be transmitted during Auto-Negotiation (32.5.4.2).

100BASE-T2 adds 100BASE-T2 full duplex and half duplex capabilities to the priority resolution table(28B.3) and MII Status Register (22.2.4.2).

T2 is defined as a valid value for “x” in 28.3.1 (e.g., link_status_T2). T2 represents that the 100BASE-T2PMA is the signal source.

28D.5 Extensions required for Clause 40 (1000BASE-T)

Clause 40 (1000BASE-T) makes special use of Auto-Negotiation and requires additional MII registers. Thisuse is summarized below. Details are provided in 40.5.

a) Auto-Negotiation is mandatory for 1000BASE-T. (40.5.1)

b) 1000BASE-T requires an ordered exchange of Next Page messages. (40.5.1.2)

c) 1000BASE-T parameters are configured based on information provided by the ordered exchange ofNEXT Page messages.

d) 1000BASE-T uses MASTER and SLAVE to define PHY operations and to facilitate the timing oftransmit and receive operations. Auto-Negotiation is used to provide information used to configureMASTER-SLAVE status.(40.5.2)

e) 1000BASE-T transmits and receives Next Pages for exchange of information related to MASTER-SLAVE operation. The information is specified in MII registers 9 and 10 (see 32.5.2 and 40.5.1.1),which are required in addition to registers 0-8 as defined in 28.2.4.

f) 1000BASE-T adds new message codes to be transmitted during Auto-Negotiation. (40.5.1.3)

g) 1000BASE-T adds 1000BASE-T full duplex and half duplex capabilities to the priority resolutiontable. (28B.3) and MII Extended Status Register (22.2.4.4)

h) 1000BASE-T is defined as a valid value for “x” in 28.3.1 (e.g., link_status_1GigT.) 1GigT repre-sents that the 1000BASE-T PMA is the signal source.

i) 1000BASE-T supports Asymmetric Pause as defined in Annex 28B.



Annex 29A

(informative)

DTE and repeater delay components

29A.1 DTE delay

Round-trip DTE delay = MAC transmit start to MDI output + MDI input to MDI output (worst case, nondeferred) + MDI input to collision detect

NOTE 1—Refer to Clauses 23, 24, 25, and 26.

NOTE 2—Worst-case values are used for the one T4 and one TX/FX value shown in Table 29–3. (TX/FX values forMAC transmit start and MDI input to collision detect; T4 value for MDI input to MDI output.)

29A.2 Repeater delay

Repeater delay= SOP (start-of-packet propagation delay) + SOJ (start-of-jam propagation delay)

NOTE—Refer to Clause 27.



Annex 29B

(informative)

Recommended topology documentation

It is strongly recommended that detailed records documenting the topology components of 100BASE-T net-works be prepared and maintained to facilitate subsequent modification. Proper 100BASE-T topologydesign requires an accurate knowledge of link segment and hub parameters to ensure proper operation ofsingle and multi-segment, single collision domain networks. Link segment documentation is site-specificand requires careful documentation. It is recommended that the information shown in Table 29B–1 be col-lected for each link segment and archived for future reference. Hub performance parameters may beobtained from manufacturer documentation.

Table 29B–1—Recommended link segment documentation

Horizontal wiring (wiring closet, from punch-down block to

end station wall plate)

MII cable(s)

Wiring closet patch cord

End station connecting

cable

Length

Type (e.g., Category 3)

Cable manufacturer

Cable code/id (from manufacturer)

Cable delay(in bit times per meter)



Annex 30A

(normative)

GDMO specification for 802.3 managed object classes

This annex formally defines the protocol encodings for CMIP and ISO/IEC 15802-2: 1995 [ANSI/IEEE Std802.1B and 802.1k, 1995 Edition] for the IEEE 802.3 Managed Objects using the templates specified inISO/IEC 10165-4: 1992. The application of a GDMO template compiler against 30A.1 to 30A.8 will pro-duce the proper protocol encodings.

NOTE 1—The arcs (that is, object identifier values) defined in Annex 30A deprecate the arcs previously defined inAnnexes H.1 (Layer Management), H.2 (Repeater Management), and H.3 (MAU Management). See IEEE Std 802.1F-1993, Annex C.4.

NOTE 2—During the update for 1000 Mb/s operation differences between objects in the root of the registration arcswere harmonized. All instances of iso(1) std(0) iso8802(8802) csma(3)... were changed to iso(1) member-body(2)us(840) 802dot3(10006)... in order to harmonize with the rest of this GDMO specification. For maximum compatibilitywith previous implementations it is recommended that all implementations respond equally to requests for communica-tion based on either registration arc.

Each attribute definition in this clause references directly by means of the WITH ATTRIBUTE SYNTAXconstruct or indirectly by means of the DERIVED FROM construct an ASN.1 type or subtype that definesthe attribute’s type and range. Those ASN.1 types and subtypes defined exclusively for CSMA/CDManagement appear in a single ASN.1 module in 30B.1.

Counters for these protocol encodings are specified as either 32 or 64 bits wide. Thirty-two bit counters areused for the protocol encoding of counter attributes, providing the minimum rollover time is 58 min or more.Sixty-four bit counters are used for the protocol encoding of counter attributes that could roll over in lessthan 58 min with a 32-bit counter. Approximate counter rollover times are provided as notes below eachcounter BEHAVIOUR definition. 1000 Mb/s counters are 10 times faster than 100 Mb/s counters, similarly100 Mb/s counters are 10 times faster than 10 Mb/s counters. For formal definition of the counter, refer tothe BEHAVIOUR bCMCounter in 30B.1.

30A.1 DTE MAC entity managed object class

30A.1.1 DTE MAC entity formal definition

oMACEntity MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;

CHARACTERIZED BYpBasic PACKAGE

ATTRIBUTES aMACID GET;ACTIONS acInitializeMAC;


pMandatory PACKAGEATTRIBUTES aFramesTransmittedOK GET,

aSingleCollisionFrames GET,



aMultipleCollisionFrames GET,aFramesReceivedOK GET,aFrameCheckSequenceErrors GET,aAlignmentErrors GET,aMACCapabilities GET,aDuplexStatus GET-SET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) macMandatoryPkg(1);

PRESENT IF Conformance to DTE Management is desired. Attributes aMACCapabilities and aDuplexStatus are mandatory in systems that can operate in full duplex mode and are recommended in systems that can only operate in half duplex mode.;

pRecommended PACKAGEATTRIBUTES aOctetsTransmittedOK GET,

aFramesWithDeferredXmissions GET,aLateCollisions GET,aFramesAbortedDueToXSColls GET,aFramesLostDueToIntMACXmitError GET,aCarrierSenseErrors GET,aOctetsReceivedOK GET,aFramesLostDueToIntMACRcvError GET,aPromiscuousStatus GET-SET,aReadMulticastAddressList GET;

ACTIONS acAddGroupAddress,acDeleteGroupAddress;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) macRecommendedPkg(2);

PRESENT IF The Recommended Package is implemented.;pOptional PACKAGE

ATTRIBUTES aMulticastFramesXmittedOK GET,aBroadcastFramesXmittedOK GET,aMulticastFramesReceivedOK GET,aBroadcastFramesReceivedOK GET,aInRangeLengthErrors GET,aOutOfRangeLengthField GET,aFrameTooLongErrors GET,aMACEnableStatus GET-SET,aTransmitEnableStatus GET-SET,aMulticastReceiveStatus GET-SET,aReadWriteMACAddress GET-SET;

ACTIONS acExecuteSelfTest;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) optionalPkg(3);PRESENT IF The Optional Package and the Recommended Package

are implemented.;pArray PACKAGE

ATTRIBUTES aCollisionFrames GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) arrayPkg(4);PRESENT IF The Array Package and the Recommended Package

are implemented.;pExcessiveDeferral PACKAGE



ATTRIBUTES aFramesWithExcessiveDeferral GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) excessiveDeferralPkg(5);

PRESENT IF The ExcessiveDeferral Package and the Recommended Package are implemented.;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) managedObjectClass(3) macObjectClass(1);

nbMACName NAME BINDING

SUBORDINATE OBJECT CLASS oMACEntity;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system;WITH ATTRIBUTE aMACID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) macName(1);

nbMACMonitor NAME BINDING

SUBORDINATE OBJECT CLASS “IEEE802.1F”:ewmaMetricMonitor;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system;WITH ATTRIBUTE aScannerId;


REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBinding(6) macMonitor(2);

nbMAC-MACControl NAME BINDING

SUBORDINATE OBJECT CLASS oMACEntity;NAMED BY SUPERIOR OBJECT CLASS oMACControlEntity;WITH ATTRIBUTE aMACID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbMAC-MACControl(16);

nbMAC-Aggregator NAME BINDING

SUBORDINATE OBJECT CLASS oMACEntity;NAMED BY SUPERIOR OBJECT CLASS oAggregator;WITH ATTRIBUTE aMACID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbMAC-Aggregator(17);

30A.1.2 DTE MAC entity attributes

aMACID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bMACID;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7) macID(1);

bMACID BEHAVIOUR

DEFINED AS See “BEHAVIOUR DEFINED AS” in 30.3.1.1.1;

aFramesTransmittedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesTransmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesTransmittedOK(2);

bFramesTransmittedOK BEHAVIOUR


The approximate minimum time between counter rollovers for 10 Mb/s opera-tion is 80 h.;

NOTE 2—This maps to framesSent (of the mandatory macPackage) in ISO/IEC10742: 1994.;

aSingleCollisionFrames ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bSingleCollisionFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) singleCollisionFrames(3);

bSingleCollisionFrames BEHAVIOUR


NOTE—The approximate minimum time between counter rollovers for 10 Mb/soperation is 103 h.;

aMultipleCollisionFrames ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bMultipleCollisionFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) multipleCollisionFrames(4);

bMultipleCollisionFrames BEHAVIOUR



aFramesReceivedOK ATTRIBUTE

DERIVED FROM aCMCounter;



BEHAVIOUR bFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesReceivedOK(5);

bFramesReceivedOK BEHAVIOUR


The approximate minimum time between counter rollovers for 10 Mb/s opera-tion is 80 h.;

NOTE 2—This maps to framesReceived (of the mandatory macPackage) inISO/IEC 10742: 1994.;

aFrameCheckSequenceErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFrameCheckSequenceErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)


bFrameCheckSequenceErrors BEHAVIOUR



aAlignmentErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bAlignmentErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)


bAlignmentErrors BEHAVIOUR



aOctetsTransmittedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bOctetsTransmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) octetsTransmittedOK(8);

bOctetsTransmittedOK BEHAVIOUR


The approximate minimum time between counter rollovers for 10 Mb/s operationis 58 min.



NOTE 2—This maps to octetsSent (of the mandatory macPackage) in ISO/IEC10742: 1994.;

aFramesWithDeferredXmissions ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesWithDeferredXmissions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesWithDeferredXmissions(9);

bFramesWithDeferredXmissions BEHAVIOUR



aLateCollisions ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bLateCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) lateCollisions(10);

bLateCollisions BEHAVIOUR



aFramesAbortedDueToXSColls ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesAbortedDueToXSColls;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesAbortedDueToXSColls(11);

bFramesAbortedDueToXSColls BEHAVIOUR


NOTE—The approximate minimum time between counter rollovers for 10 Mb/soperation is 53 days.;

aFramesLostDueToIntMACXmitError ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesLostDueToIntMACXmitError;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesLostDueToIntMACXmitError(12);

bFramesLostDueToIntMACXmitError BEHAVIOUR





aCarrierSenseErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bCarrierSenseErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) carrierSenseErrors(13);

bCarrierSenseErrors BEHAVIOUR



aOctetsReceivedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bOctetsReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) octetsReceivedOK(14);

bOctetsReceivedOK BEHAVIOUR


The approximate minimum time between counter rollovers for 10 Mb/s opera-tion is 58 min.

This maps to octetsReceived (of the mandatory macPackage) in ISO/IEC 10742:1994.;

aFramesLostDueToIntMACRcvError ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesLostDueToIntMACRcvError;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesLostDueToIntMACRcvError(15);

bFramesLostDueToIntMACRcvError BEHAVIOUR



aPromiscuousStatus ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse;BEHAVIOUR bPromiscuousStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) promiscuousStatus(16);



bPromiscuousStatus BEHAVIOUR


aReadMulticastAddressList ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MulticastAddressList

BEHAVIOUR bReadMulticastAddressList;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) readMulticastAddressList(17);

bReadMulticastAddressList BEHAVIOUR


aMulticastFramesXmittedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bMulticastFramesXmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) multicastFramesXmittedOK(18);

bMulticastFramesXmittedOK BEHAVIOUR



aBroadcastFramesXmittedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bBroadcastFramesXmittedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) broadcastFramesXmittedOK(19);

bBroadcastFramesXmittedOK BEHAVIOUR



aFramesWithExcessiveDeferral ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesWithExcessiveDeferral;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesWithExcessiveDeferral(20);

bFramesWithExcessiveDeferral BEHAVIOUR





aMulticastFramesReceivedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bMulticastFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) multicastFramesReceivedOK(21);

bMulticastFramesReceivedOK BEHAVIOUR



aBroadcastFramesReceivedOK ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bBroadcastFramesReceivedOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) broadcastFramesReceivedOK(22);

bBroadcastFramesReceivedOK BEHAVIOUR



aInRangeLengthErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bInRangeLengthErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) inRangeLengthErrors(23);

bInRangeLengthErrors BEHAVIOUR



aOutOfRangeLengthField ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bOutOfRangeLengthField;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) outOfRangeLengthField(24);

bOutOfRangeLengthField BEHAVIOUR





aFrameTooLongErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFrameTooLongErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) frameTooLongErrors(25);

bFrameTooLongErrors BEHAVIOUR



aMACEnableStatus ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse;BEHAVIOUR bMACEnableStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mACEnableStatus(26);

bMACEnableStatus BEHAVIOUR


aTransmitEnableStatus ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse;BEHAVIOUR bTransmitEnableStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) transmitEnableStatus(27);

bTransmitEnableStatus BEHAVIOUR


aMulticastReceiveStatus ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse;BEHAVIOUR bMulticastReceiveStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) multicastReceiveStatus(28);

bMulticastReceiveStatus BEHAVIOUR


aReadWriteMACAddress ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802CommonDefinitions.MACAddress;BEHAVIOUR bReadWriteMACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)



attribute(7) modifyMACAddress(29);

bReadWriteMACAddress BEHAVIOUR


NOTE—This maps to localMACAddress (of the mandatory macPackage) in ISO/IEC 10742: 1994.;

aCollisionFrames ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AttemptArray;BEHAVIOUR bCollisionFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) collisionFrames(30);

bCollisionFrames BEHAVIOUR


NOTE—The approximate minimum time for any single counter rollover for10 Mb/s operation is 103 h.;

aMACCapabilities ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACCapabilitiesList;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMACCapabilities;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) aMACCapabilities(89);

bMACCapabilities BEHAVIOUR


aDuplexStatus ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.DuplexValues;MATCHES FOR EQUALITY;BEHAVIOUR bDuplexStatus;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) aDuplexStatus(90);

bDuplexStatus BEHAVIOUR


30A.1.3 DTE MAC entity actions

acInitializeMAC ACTION

BEHAVIOUR bInitializeMAC;MODE CONFIRMED;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) action(9) initializeMAC(1);

bInitializeMAC BEHAVIOUR


acAddGroupAddress ACTION

BEHAVIOUR bAddGroupAddress;MODE CONFIRMED;WITH INFORMATION SYNTAX IEEE802CommonDefinitions.MACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) addGroupAddress(2);

bAddGroupAddress BEHAVIOUR


acDeleteGroupAddress ACTION

BEHAVIOUR bDeleteGroupAddress;MODE CONFIRMED;WITH INFORMATION SYNTAX IEEE802CommonDefinitions.MACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) deleteGroupAddress(3);

bDeleteGroupAddress BEHAVIOUR


acExecuteSelfTest ACTION

BEHAVIOUR bExecuteSelfTestMAC;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) executeSelfTestMAC(4);

bExecuteSelfTestMAC BEHAVIOUR


30A.2 DTE physical entity managed object class

30A.2.1 DTE physical entity formal definition

oPHYEntity MANAGED OBJECT CLASS


CHARACTERIZED BYpBasic PACKAGE

ATTRIBUTES aPHYID GET,



aPHYType GET,

aPHYTypeList GET,

aMIIDetect GET,

aPHYAdminState GET;

;

;

CONDITIONAL PACKAGES

pRecommended PACKAGE

ATTRIBUTES aSQETestErrors GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) phyRecommendedPkg(6);

PRESENT IF The Recommended Package is implemented.;

pMultiplePhy PACKAGE

ACTIONS acPHYAdminControl;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) phyMultiplePhyPkg(7);

PRESENT IF There is more than one PHY per MAC.;

p100MbpsMonitor PACKAGE

ATTRIBUTES aSymbolErrorDuringCarrier GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) phy100MbpsMonitor(8);

PRESENT IF The 100/1000 Mb/s Monitor capability is implemented.;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) managedObjectClass(3) phyObjectClass(2);

nbPHYName NAME BINDING

SUBORDINATE OBJECT CLASS oPHYEntity;

NAMED BY SUPERIOR OBJECT CLASSoMACEntity;

WITH ATTRIBUTE aPHYID;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBinding(6) phyName(3);

nbPHYMonitor NAME BINDING

SUBORDINATE OBJECT CLASS “IEEE802.1F”:ewmaMetricMonitor;

NAMED BY SUPERIOR OBJECT CLASS“ISO/IEC 10165-2”:system;

WITH ATTRIBUTE aScannerId;

CREATE WITH-AUTOMATIC-INSTANCE-NAMING;

DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBinding(6) phyMonitor(4);



30A.2.2 DTE physical entity attributes

aPHYID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bPHYID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) phyID(31);

bPHYID BEHAVIOUR


aPHYType ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PhyTypeValue;

MATCHES FOR EQUALITY;BEHAVIOUR bPHYType;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) phyType(32);

bPHYType BEHAVIOUR


aPHYTypeList ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PhyTypeList;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bPHYTypeList;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) phyTypeList(33);

bPHYTypeList BEHAVIOUR


aSQETestErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bSQETestErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) sqeTestErrors(34);

bSQETestErrors BEHAVIOUR





aSymbolErrorDuringCarrier ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bSymbolErrorDuringCarrier;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) symbolErrorDuringCarrier(35);

bSymbolErrorDuringCarrier BEHAVIOUR



aMIIDetect ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MIIDetect;MATCHES FOR EQUALITY;BEHAVIOUR bMIIDetect;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mIIDetect(36);

bMIIDetect BEHAVIOUR


aPHYAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bPHYAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) phyAdminState(37);

bPHYAdminState BEHAVIOUR


30A.2.3 DTE physical entity actions

acPHYAdminControl ACTION

BEHAVIOUR bPHYAdminControl;MODE CONFIRMED;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

PortAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) phyAdminControl(5);

bPHYAdminControl BEHAVIOUR




30A.3 DTE MAC control entity managed object class

30A.3.1 DTE MAC control entity formal definition

oMACControlEntity MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992":top;

CHARACTERIZED BYpMandatory PACKAGE

ATTRIBUTES aMACControlFunctionsSupported GET-SET;;

;

CONDITIONAL PACKAGESpRecommended PACKAGE

ATTRIBUTES aMACControlFramesTransmitted GET,aMACControlFramesReceived GET,aUnsupportedOpcodesReceived GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)csmacdmgt(30)package(4) macControlRecommendedPkg(17);

PRESENT IF The Recommended Package is implemented.;

REGISTERED ASiso(1) member-body(2) us(840) 802dot3(10006)csmacdmgt(30)managedObjectClass(3) macControlObjectClass(8);

nbMACControl-System NAME BINDING

SUBORDINATE OBJECT CLASS oMACControlEntity;NAMED BY SUPERIOR OBJECT CLASS “ISO/IEC 10165-2”:system;WITH ATTRIBUTE aMACControlID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbMACControl-System(18);

nbMACControl-Aggregator NAME BINDING

SUBORDINATE OBJECT CLASS oMACControlEntity;NAMED BY SUPERIOR OBJECT CLASS oAggregator;WITH ATTRIBUTE aMACControlID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbMACControl-Aggregator(19);

nbMACControlMonitor NAME BINDING

SUBORDINATE OBJECT CLASS"IEEE802.1F":ewmaMetricMonitor;

NAMED BY SUPERIOR OBJECT CLASS

"ISO/IEC 10165-2":system;

WITH ATTRIBUTEaScannerId;CREATE WITH-AUTOMATIC-INSTANCE-NAMING;DELETE ONLY-IF-NO-CONTAINED-OBJECTS;

REGISTERED ASiso(1) member-body(2) us(840) 802dot3(10006)csmacdmgt(30) nameBinding(6) macControlMonitor(15);



30A.3.2 DTE MAC Control entity attributes

aMACControlID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOR bMACControlID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aMACControlID(92);

bMACControlID BEHAVIOR

DEFINED AS See "BEHAVIOR DEFINED AS" in 30.3.3.1;

aMACControlFunctionsSupported ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACControlFunctionsList;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOR bMACControlFunctionsSupported;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aMACControlFunctionsSupported(93);

bMACControlFunctionsSupported BEHAVIOR


aMACControlFramesTransmitted ATTRIBUTE

WITH ATTRIBUTE SYNTAX aCMCounter;BEHAVIOR bMACControlFramesTransmitted;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aMACControlFramesTransmitted(94);

bMACControlFramesTransmitted BEHAVIOR


aMACControlFramesReceived ATTRIBUTE

WITH ATTRIBUTE SYNTAX aCMCounter;BEHAVIOR bMACControlFramesReceived;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aMACControlFramesReceived(95);

bMACControlFramesReceived BEHAVIOR


aUnsupportedOpcodesReceived ATTRIBUTE

WITH ATTRIBUTE SYNTAX aCMCounter;BEHAVIOR bUnsupportedOpcodesReceived;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aUnsupportedOpcodesReceived(96);



bUnsupportedOpcodesReceived BEHAVIOR


30A.4 DTE MAC Control function entity managed object class

30A.4.1 DTE MAC Control function entity formal definition

oMACControlFunctionEntityMANAGED OBJECT CLASS

DERIVED FROM"CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992":top;

CHARACTERIZED BYpMandatory PACKAGE

ATTRIBUTES aPAUSELinkDelayAllowance GET-SET;;

;

CONDITIONAL PACKAGESpRecommended PACKAGE

ATTRIBUTES aPAUSEMACCtrlFramesTransmitted GET,aPAUSEMACCtrlFramesReceived GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)csmacdmgt(30)package(4) macControlFunctionRecomendedPkg(17);

PRESENT IF The Recommended Package is implemented.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30)managedObjectClass(3)macControlFunctionObjectClass(9);

30A.4.2 DTE MAC Control function entity attributes

aPAUSELinkDelayAllowance ATTRIBUTE

WITH ATTRIBUTE SYNTAX LinkDelayAllowance;BEHAVIOR bPAUSELinkDelayAllowance;REGISTERED AS iso(1) memberbody(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aPAUSELinkDelayAllowance(97);

bPAUSELinkDelayAllowance BEHAVIOR

DEFINED AS See “BEHAVIOR DEFINED AS” in 30.3.4.1;

aPAUSEMACCtrlFramesTransmitted ATTRIBUTE

WITH ATTRIBUTE SYNTAX aCMCounter;BEHAVIOR bPAUSEMACCtrlFramesTransmitted;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aPAUSEMACCtrlFramesTransmitted(98);

bPAUSEMACCtrlFramesTransmitted BEHAVIOR




aPAUSEMACCtrlFramesReceived ATTRIBUTE

WITH ATTRIBUTE SYNTAX aCMCounter;BEHAVIOR bPAUSEMACCtrlFramesReceived;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) attribute(7) aPAUSEMACCtrlFramesReceived(99);

bPAUSEMACCtrlFramesReceived BEHAVIOR


30A.5 Repeater managed object class

30A.5.1 Repeater, formal definition

oRepeater MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 1992”:top;

CHARACTERIZED BYpRepeaterBasicControl PACKAGE

ATTRIBUTES aRepeaterID GET,aRepeaterType GET,aRepeaterGroupCapacity GET,aGroupMap GET,aRepeaterHealthState GET,aRepeaterHealthText GET,aRepeaterHealthData GET;

ACTIONS acResetRepeater,acExecuteNonDisruptiveSelfTest;

NOTIFICATIONS nRepeaterHealth,nRepeaterReset,nGroupMapChange;


pRepeaterPerfMonitor PACKAGEATTRIBUTES aTransmitCollisions GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) repeaterPerfMonitorPkg(9);

PRESENT IF The Performance Monitor Capability is implemented.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

managedObjectClass(3) repeaterObjectClass(3);

nbRepeaterName NAME BINDING

SUBORDINATE OBJECT CLASS repeater;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system AND SUBCLASSES;WITH ATTRIBUTE aRepeaterID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) repeaterName(5);



nbRepeaterMonitor NAME BINDING

SUBORDINATE OBJECT CLASS “IEEE802.1F”:oEWMAMetricMonitor;NAMED BY SUPERIOR OBJECT CLASS

“ISO/IEC 10165-2”:system AND SUBCLASSES;WITH ATTRIBUTE aScannerId;


REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBinding(6) repeaterMonitor(6);

30A.5.2 Repeater attributes

aRepeaterID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterID(38);

bRepeaterID BEHAVIOUR

DEFINED AS See “BEHAVIOUR DEFINED AS” in 30.4.1.1.1.

aRepeaterType ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RepeaterType;MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterType;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterType (39);

bRepeaterType BEHAVIOUR


aRepeaterGroupCapacity ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bRepeaterGroupCapacity;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterGroupCapacity(40);

bRepeaterGroupCapacity BEHAVIOUR


aGroupMap ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;



MATCHES FOR EQUALITY;BEHAVIOUR bGroupMap;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7) groupMap(41);

bGroupMap BEHAVIOUR


aRepeaterHealthState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RepeaterHealthState;

MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterHealthState(42);

bRepeaterHealthState BEHAVIOUR


aRepeaterHealthText ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RepeaterHealthText;

MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthText;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterHealthText(43);

bRepeaterHealthText BEHAVIOUR


aRepeaterHealthData ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RepeaterHealthData;

MATCHES FOR EQUALITY;BEHAVIOUR bRepeaterHealthData;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) repeaterHealthData(44);

bRepeaterHealthData BEHAVIOUR


aTransmitCollisions ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bTransmitCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)



attribute(7) transmitCollisions (45);

bTransmitCollisions BEHAVIOUR


NOTE—The approximate minimum time for counter rollover for 10 Mb/s oper-ation is 16 h.

30A.5.3 Repeater actions

acResetRepeater ACTION

BEHAVIOUR bResetRepeater;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) resetRepeater(6);

bResetRepeater BEHAVIOUR


acExecuteNonDisruptiveSelfTest ACTION

BEHAVIOUR bExecuteNonDisruptiveSelfTest;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) executeNonDisruptiveSelfTestAction(7);

bExecuteNonDisruptiveSelfTest BEHAVIOUR


30A.5.4 Repeater notifications

nRepeaterHealth NOTIFICATION

BEHAVIOUR bRepeaterHealth;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

RepeaterHealthInfoAND ATTRIBUTE IDS repeaterHealthState aRepeaterHealthState,

repeaterHealthText aRepeaterHealthText,repeaterHealthData aRepeaterHealthData

;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

notification(10) repeaterHealth(1);

bRepeaterHealth BEHAVIOUR


nRepeaterReset NOTIFICATION

BEHAVIOUR bRepeaterReset;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.



RepeaterHealthInfoAND ATTRIBUTE IDS repeaterHealthState aRepeaterHealthState,

repeaterHealthText aRepeaterHealthText,repeaterHealthData aRepeaterHealthData

;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

notification(10) repeaterReset(2);

bRepeaterReset BEHAVIOUR


nGroupMapChange NOTIFICATION

BEHAVIOUR bGroupMapChange;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

notification(10) groupMapChange(3);

bGroupMapChange BEHAVIOUR


30A.6 Group managed object class

30A.6.1 Group, formal definition

oGroup MANAGED OBJECT CLASS


CHARACTERIZED BYpGroupBasicControl PACKAGE

ATTRIBUTES aGroupID GET,aGroupPortCapacity GET,aPortMap GET;

NOTIFICATIONS nPortMapChange;;

;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) managedObjectClass(3) groupObjectClass(4);

nbGroupName NAME BINDING

SUBORDINATE OBJECT CLASS oGroup;NAMED BY SUPERIOR OBJECT CLASS

oRepeater AND SUBCLASSES;WITH ATTRIBUTE aGroupID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) groupName(7);



30A.6.2 Group attributes

aGroupID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bGroupID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) groupID(46);

bGroupID BEHAVIOUR


aGroupPortCapacity ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bGroupPortCapacity;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) groupPortCapacity(47);

bGroupPortCapacity BEHAVIOUR


aPortMap ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;MATCHES FOR EQUALITY;BEHAVIOUR bPortMap;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) portMap(48);

bPortMap BEHAVIOUR


30A.6.3 Group notifications

nPortMapChange NOTIFICATION

BEHAVIOUR bPortMapChange;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.BitString;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

notification(10) portMapChange(4);

bPortMapChange BEHAVIOUR




30A.7 Repeater port managed object class

30A.7.1 Port, formal definition

oRepeaterPort MANAGED OBJECT CLASS


CHARACTERIZED BYpPortBasicControl PACKAGE

ATTRIBUTES aPortID GET,aPortAdminState GET,aAutoPartitionState GET;

ACTIONS acPortAdminControl;;


pPortPerfMonitor PACKAGEATTRIBUTES aReadableFrames GET,

aReadableOctets GET,aFrameCheckSequenceErrors GET,aAlignmentErrors GET,aFramesTooLong GET,aShortEvents GET,aRunts GET,aCollisions GET,aLateEvents GET,aVeryLongEvents GET,aDataRateMismatches GET,aAutoPartitions GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) package(4) portPerfMonitorPkg(10);

PRESENT IF The Performance Monitor Capability is implemented.;pPortAddrTracking PACKAGE

ATTRIBUTES aLastSourceAddress GET,aSourceAddressChanges GET;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)csmacdmgt(30) package(4) portAddrTrackPkg(11);

PRESENT IF The Address Tracking and Performance Monitor capabilities are implemented.;

p100MbpsMonitor PACKAGEATTRIBUTES aIsolates GET,

aSymbolErrorDuringPacket GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) port100MbpsMonitor(12);

PRESENT IF The 100/1000 Mb/s Monitor capability is implemented;

pBurst PACKAGEATTRIBUTES aBursts GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4)



portBurst(18);PRESENT IF The 1000 Mb/s Burst Monitor capability is

implemented;

REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) managedObjectClass(3) repeaterPortObjectClass(5);

nbPortName NAME BINDING

SUBORDINATE OBJECT CLASS oRepeaterPort;NAMED BY SUPERIOR OBJECT CLASS

oGroup AND SUBCLASSES;WITH ATTRIBUTE aPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) portName(8);

30A.7.2 Port attributes

aPortID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;BEHAVIOUR bPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) portID(49);

bPortID BEHAVIOUR


aPortAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState;

MATCHES FOR EQUALITY;BEHAVIOUR bPortAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) portAdminState(50);

bPortAdminState BEHAVIOUR


aAutoPartitionState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoPartitionState;

MATCHES FOR EQUALITY;BEHAVIOUR bAutoPartition;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoPartitionState(51);

bAutoPartition BEHAVIOUR




aReadableFrames ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bReadableFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) readableFrames(52);

bReadableFrames BEHAVIOUR



aReadableOctets ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bReadableOctets;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) readableOctets(53);

bReadableOctets BEHAVIOUR


NOTE—The approximate minimum time between counter rollovers for 10 Mb/soperation is 58 min.;

aFrameCheckSequenceErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFCSErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)


bFCSErrors BEHAVIOUR



aAlignmentErrors ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bAlignmentErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)


bAlignmentErrors BEHAVIOUR





aFramesTooLong ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bFramesTooLong;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) framesTooLong(56);

bFramesTooLong BEHAVIOUR



aShortEvents ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bShortEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) shortEvents(57);

bShortEvents BEHAVIOUR


NOTE—The approximate minimum time between counter rollovers for 10 Mb/soperation is 16 hours;

aRunts ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bRunts;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) runts(58);

bRunts BEHAVIOUR


NOTE—The approximate minimum time for counter rollover for 10 Mb/s opera-tion is 16 h.;

aCollisions ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bCollisions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) collisions(59);

bCollisions BEHAVIOUR





aLateEvents ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bLateEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) lateEvents(60);

bLateEvents BEHAVIOUR



aVeryLongEvents ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bVeryLongEvents;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) veryLongEvents(61);

bVeryLongEvents BEHAVIOUR



aDataRateMismatches ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bDataRateMismatches;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) dataRateMismatches(62);

bDataRateMismatches BEHAVIOUR


aAutoPartitions ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bAutoPartitions;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoPartitions(63);

bAutoPartitions BEHAVIOUR


aIsolates ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bIsolates;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)



attribute(7) isolates(64);

bIsolates BEHAVIOUR


aSymbolErrorDuringPacket ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bSymbolErrorDuringPacket;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) symbolErrorDuringPacket(65);

bSymbolErrorDuringPacket BEHAVIOUR


aLastSourceAddress ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802CommonDefinitions.MACAddress;MATCHES FOR EQUALITY;BEHAVIOUR bLastSourceAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) lastSourceAddress(66);

bLastSourceAddress BEHAVIOUR


aSourceAddressChanges ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bSourceAddressChanges;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) sourceAddressChanges(67);

bSourceAddressChanges BEHAVIOUR



aBursts ATTRIBUTE

DERIVED FROM aCMCounter;BEHAVIOUR bBursts;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) bursts(100);

bBursts BEHAVIOUR




30A.7.3 Port actions

acPortAdminControl ACTION

BEHAVIOUR bPortAdminControl;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

PortAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) portAdminControl(8);

bPortAdminControl BEHAVIOUR


30A.8 MAU managed object class

30A.8.1 MAU, formal definition

oMAU MANAGED OBJECT CLASS


CHARACTERIZED BYpMAUBasic PACKAGE

ATTRIBUTES aMAUID GET,aMAUType GET-SET,aMAUTypeList GET,aMediaAvailable GET,aJabber GET,aMAUAdminState GET;

NOTIFICATIONS nJabber;;


pMAUControl PACKAGEACTIONS acResetMAU,

acMAUAdminControl;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) mauControlPkg(13);

PRESENT IF The pMAUControl package is implemented.;

pMediaLossTracking PACKAGEATTRIBUTES aLoseMediaCounter GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) mediaLossTrackingPkg(14);

PRESENT IF MAU TypeValue = AUI or if the pMediaLossTracking package is implemented.;

pBroadbandDTEMAU PACKAGEATTRIBUTES aBbMAUXmitRcvSplitType GET,



aBroadbandFrequencies GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) broadbandMAUPkg(15);

PRESENT IF The MAU is of type 10BROAD36.;

p100MbpsMonitor PACKAGEATTRIBUTES aFalseCarriers GET;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) package(4) mau100MbpsMonitor(16);

PRESENT IF The MAU is capable of 100 Mb/s operation.;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006)

csmacdmgt(30) managedObjectClass(3) mauObjectClass(6);

nbMAU-repeaterName NAME BINDING

SUBORDINATE OBJECT CLASS oMAU;NAMED BY SUPERIOR OBJECT CLASS --(of oRepeaterPort)

oRepeaterPort AND SUBCLASSES;--1.2.840.10006.30.3.5

WITH ATTRIBUTE aMAUID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) mau-repeaterName(9);

nbMAU-dteName NAME BINDING

SUBORDINATE OBJECT CLASS oMAU;NAMED BY SUPERIOR OBJECT CLASS --(of oPHYEntity)

oPHYEntity AND SUBCLASSES--1.2.840.10006.30.3.2;


nameBinding(6) mau-dteName(10);

30A.8.2 MAU attributes

aMAUID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bMAUID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauID(68);

bMAUID BEHAVIOUR




aMAUType ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TypeValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMAUType;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauType(69);

bMAUType BEHAVIOUR


aMAUTypeList ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TypeList;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMAUTypeList;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauTypeList(70);

bMAUTypeList BEHAVIOUR


aMediaAvailable ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MediaAvailState;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMediaAvailable;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauMediaAvailable(71);

bMediaAvailable BEHAVIOUR


aLoseMediaCounter ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bLoseMediaCounter;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauLoseMediaCounter(72);

bLoseMediaCounter BEHAVIOUR


aJabber ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Jabber;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bJabberAttribute;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7) jabber(73);

bJabberAttribute BEHAVIOUR


aMAUAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AdminState;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bMAUAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) mauAdminState(74);

bMAUAdminState BEHAVIOUR


aBbMAUXmitRcvSplitType ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.BbandXmitRcvSplitType;

MATCHES FOR EQUALITY;BEHAVIOUR bBbMAUXmitRcvSplitType;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) bBandSplitType(75);

bBbMAUXmitRcvSplitType BEHAVIOUR


aBroadbandFrequencies ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.BbandFrequency;

MATCHES FOR EQUALITY;BEHAVIOUR bBroadbandFrequencies;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) bBandFrequencies(76);

bBroadbandFrequencies BEHAVIOUR


aFalseCarriers ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bFalseCarriers;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) falseCarriers(77);



bFalseCarriers BEHAVIOUR


aIdleErrorCount ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RegisterEight;BEHAVIOUR bIdleErrorCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) idleErrorCount(91);

bIdleErrorCount BEHAVIOUR

DEFINED AS See "BEHAVIOUR DEFINED AS" in 30.5.1.1.11;

30A.8.3 MAU actions

acResetMAU ACTION

BEHAVIOUR bResetMAU;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) resetMAU(9);

bResetMAU BEHAVIOUR


acMAUAdminControl ACTION

BEHAVIOUR bMAUAdminControl;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.AdminState;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) mauAdminCtrl(10);

bMAUAdminControl BEHAVIOUR


30A.8.4 MAU notifications

nJabber NOTIFICATION

BEHAVIOUR bJabberNotification;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.Jabber;;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

notification(10) jabber(5);

bJabberNotification BEHAVIOUR




30A.9 AutoNegotiation managed object class

30A.9.1 AutoNegotiation, formal definition

oAutoNegotiation MANAGED OBJECT CLASS


CHARACTERIZED BYpAutoNeg PACKAGE

ATTRIBUTES aAutoNegID GET,aAutoNegAdminState GET,aAutoNegRemoteSignaling GET,aAutoNegAutoConfig GET-SET,aAutoNegLocalTechnologyAbilityGET,aAutoNegAdvertisedTechnologyAbilityGET-SET,aAutoNegReceivedTechnologyAbilityGET,aAutoNegLocalSelectorAbility GET,aAutoNegAdvertisedSelectorAbilityGET-SET,aAutoNegReceivedSelectorAbilityGET;

ACTIONSacAutoNegRestartAutoConfig,acAutoNegAdminControl;

;;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

managedObjectClass(3) autoNegObjectClass(7);

nbAutoNeg-mauName NAME BINDING

SUBORDINATE OBJECT CLASS oMAU;NAMED BY SUPERIOR OBJECT CLASS --(of oMAU)

oMAU AND SUBCLASSES;--1.2.840.10006.30.3.6


nameBinding(6) autoNeg-mauName(11);

30A.9.2 Auto-Negotiation attributes

aAutoNegID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName;MATCHES FOR EQUALITY;BEHAVIOUR bAutoNegID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegID(78);

bAutoNegID BEHAVIOUR




aAutoNegAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoNegAdminState;

MATCHES FOR EQUALITY;BEHAVIOUR bAutoNegAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegAdminState(79);

bAutoNegAdminState BEHAVIOUR


aAutoNegRemoteSignaling ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoNegRemoteSignalingDetect;

MATCHES FOR EQUALITY;BEHAVIOUR bAutoNegRemoteSignaling;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegRemoteSignaling(80);

bAutoNegRemoteSignaling BEHAVIOUR


aAutoNegAutoConfig ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoNegAutoConfig;

MATCHES FOR EQUALITY;BEHAVIOUR bAutoNegAutoConfig;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegAutoConfig(81);

bAutoNegAutoConfig BEHAVIOUR


aAutoNegLocalTechnologyAbility ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoNegTechnologyList;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegLocalTechnologyAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegLocalTechnologyAbility(82);

bAutoNegLocalTechnologyAbility BEHAVIOUR




aAutoNegAdvertisedTechnologyAbility ATTRIBUTE


MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegAdvertisedTechnologyAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegAdvertisedTechnologyAbility(83);

bAutoNegAdvertisedTechnologyAbility BEHAVIOUR


aAutoNegReceivedTechnologyAbility ATTRIBUTE


MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegReceivedTechnologyAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegReceivedTechnologyAbility(84);

bAutoNegReceivedTechnologyAbility BEHAVIOUR


aAutoNegLocalSelectorAbility ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AutoNegSelectorList;

MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegLocalSelectorAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegLocalSelectorAbility(85);

bAutoNegLocalSelectorAbility BEHAVIOUR


aAutoNegAdvertisedSelectorAbility ATTRIBUTE


MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegAdvertisedSelectorAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegAdvertisedSelectorAbility(86);

bAutoNegAdvertisedSelectorAbility BEHAVIOUR




aAutoNegReceivedSelectorAbility ATTRIBUTE


MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAutoNegReceivedSelectorAbility;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) autoNegReceivedSelectorAbility(87);

bAutoNegReceivedSelectorAbility BEHAVIOUR


30A.9.3 AutoNegotiation actions

acAutoNegRestartAutoConfig ACTION

BEHAVIOUR bAutoNegRestartAutoConfig;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) autoNegRestartAutoConfig(11);

bAutoNegRestartAutoConfig BEHAVIOUR


acAutoNegAdminControl ACTION

BEHAVIOUR bAutoNegAdminControl;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.

AutoNegAdminState;MODE CONFIRMED;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

action(9) autoNegAdminCtrl(12);

bAutoNegAdminControl BEHAVIOUR


30A.10 ResourceTypeID managed object class

30A.10.1 ResourceTypeID, formal definition

— Implementation of this managed object in accordance with the definition contained in IEEE Std— 802.1F-1993 is a conformance requirement of this standard.— NOTE—A single instance of the Resource Type ID managed object exists within the oMACEntity— managed object class, a single instance of the Resource Type ID managed object exists within — the oRepeater managed object class, and a single instance of the Resource Type ID managed— object exists within the oMAU managed object class conditional on the presence of an MII.— The managed object itself is contained in IEEE Std 802.1F-1993, therefore only name bindings— appear in this standard;



nbResourceTypeID-mac NAME BINDING

SUBORDINATE OBJECT CLASS “IEEE802.1F”:oResourceTypeID;NAMED BY SUPERIOR OBJECT CLASS

oMACEntity;WITH ATTRIBUTE “IEEE802.1F”:aResourceTypeIDName;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) resourceTypeID-mac(12);

nbResourceTypeID-repeater NAME BINDING


oRepeater AND SUBCLASSES;WITH ATTRIBUTE “IEEE802.1F”:aResourceTypeIDName;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) resourceTypeID-repeater(13);

nbResourceTypeID-mau NAME BINDING


oMAU AND SUBCLASSES;WITH ATTRIBUTE “IEEE802.1F”:aResourceTypeIDName;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

nameBinding(6) resourceTypeID-mau(14);

30A.11 Aggregator managed object class

30A.11.1 Aggregator, formal definition

oAggregator MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;CHARACTERIZED BY

pAggregatorBasic PACKAGEATTRIBUTES aAggID GET;


pAggregatorMandatory PACKAGEATTRIBUTES aAggDescription GET,

aAggName GET-REPLACE,aAggActorSystemID GET-REPLACE,aAggActorSystemPriority GET-REPLACE,aAggAggregateOrIndividual GET,aAggActorAdminKey GET-REPLACE,aAggActorOperKey GET,aAggMACAddress GET,aAggPartnerSystemID GET,aAggPartnerSystemPriority GET,aAggPartnerOperKey GET,aAggAdminState GET-REPLACE,



aAggOperState GET,aAggTimeOfLastOperChange GET,aAggDataRate GET,aAggFramesTxOK GET,aAggFramesRxOK GET,aAggLinkUpDownNotificationEnable GET-REPLACE,aAggCollectorMaxDelay GET-REPLACE;

NOTIFICATIONSnAggLinkUpNotification,nAggLinkDownNotification;

REGISTERED ASiso(1) member-body(2) us(840) 802dot3(10006) csmacd-

mgt(30) package(4) pAggregatorMandatory(19);PRESENT IF Conformance to Link Aggregation management is desired;

pAggregatorRecommendedPACKAGEATTRIBUTES aAggOctetsTxOK GET,

aAggOctetsRxOK GET,aAggFramesDiscardedOnTx GET,aAggFramesDiscardedOnRx GET,aAggFramesWithTxErrors GET,aAggFramesWithRxErrors GET,aAggUnknownProtocolFrames GET,aAggPortList GET;


mgt(30) package(4) pAggregatorRecommended(20);PRESENT IF The recommended package is implemented;

pAggregatorOptional PACKAGEATTRIBUTES aAggMulticastFramesTxOK GET,

aAggMulticastFramesRxOK GET,aAggBroadcastFramesTxOK GET,aAggBroadcastFramesRxOK GET;


mgt(30) package(4) pAggregatorOptional(21);PRESENT IF The optional package is implemented;

;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) managedOb-

jectClass(3) oAggregator(10);

nbAggregatorName NAME BINDING

SUBORDINATE OBJECT CLASS oAggregator;NAMED BY SUPERIOR OBJECT CLASS “ISO/IEC 10165-2”:system;WITH ATTRIBUTE aAggIDREGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbAggregatorName(20);

30A.11.2 Aggregator attributes

aAggID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggID;



MATCHES FOR EQUALITY;BEHAVIOUR bAggID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggID(101);

bAggID BEHAVIOUR


aAggDescription ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.DescriptionString;MATCHES FOR EQUALITY;BEHAVIOUR bAggDescription;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggDescription(102);

bAggDescription BEHAVIOUR


aAggName ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.DescriptionString;MATCHES FOR EQUALITY;BEHAVIOUR bAggName;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggName(103);

bAggName BEHAVIOUR


aAggActorSystemID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggActorSystemID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggActorSystemID(104);

bAggActorSystemID BEHAVIOUR


aAggActorSystemPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggActorSystemPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggActorSystemPriority(105);



bAggActorSystemPriority BEHAVIOUR


aAggAggregateOrIndividual ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggOrInd;MATCHES FOR EQUALITY;BEHAVIOUR bAggAggregateOrIndividual;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggAggregateOrIndividual(106);

bAggAggregateOrIndividual BEHAVIOUR


aAggActorAdminKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggActorAdminKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggActorAdminKey(107);

bAggActorAdminKey BEHAVIOUR


aAggActorOperKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggActorOperKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggActorOperKey(108);

bAggActorOperKey BEHAVIOUR


aAggMACAddress ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggMACAddress;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggMACAddress(109);

bAggMACAddress BEHAVIOUR




aAggPartnerSystemID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPartnerSystemID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPartnerSystemID(110);

bAggPartnerSystemID BEHAVIOUR


aAggPartnerSystemPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPartnerSystemPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPartnerSystemPriority(111);

bAggPartnerSystemPriority BEHAVIOUR


aAggPartnerOperKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggPartnerOperKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPartnerOperKey(112);

bAggPartnerOperKey BEHAVIOUR


aAggAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggState;MATCHES FOR EQUALITY;BEHAVIOUR bAggAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggAdminState(113);

bAggAdminState BEHAVIOUR


aAggOperState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggState;MATCHES FOR EQUALITY;BEHAVIOUR bAggOperState ;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)aAggOperState(114);

bAggOperState BEHAVIOUR


aAggTimeOfLastOperChange ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggTimeOfLastOperChange;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggTimeOfLastOperChange(115);

bAggTimeOfLastOperChange BEHAVIOUR


aAggDataRate ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggDataRate;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggDataRate;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggDataRate(116);

bAggDataRate BEHAVIOUR


aAggOctetsTxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggOctetsTxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggOctetsTxOK(117);

bAggOctetsTxOK BEHAVIOUR


NOTE—This counter has a maximum increment rate of 1 230 000 counts per second at 10 Mb/s.;

aAggOctetsRxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggOctetsRxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggOctetsRxOK(118);



bAggOctetsRxOK BEHAVIOUR


NOTE—This counter has a maximum increment rate of 1 230 000 counts per second at 10 Mb/s.;

aAggFramesTxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesTxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesTxOK(119);

bAggFramesTxOK BEHAVIOUR


NOTE—This counter has a maximum increment rate of 16 000 counts per second at 10 Mb/s.;

aAggFramesRxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesRxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesRxOK(120);

bAggFramesRxOK BEHAVIOUR



aAggMulticastFramesTxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggMulticastFramesTxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggMulticastFramesTxOK(121);

bAggMulticastFramesTxOK BEHAVIOUR



aAggMulticastFramesRxOK ATTRIBUTE

DERIVED FROM aCMCounter;



MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggMulticastFramesRxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggMulticastFramesRxOK(122);

bAggMulticastFramesRxOK BEHAVIOUR



aAggBroadcastFramesTxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggBroadcastFramesTxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggBroadcastFramesTxOK(123);

bAggBroadcastFramesTxOK BEHAVIOUR



aAggBroadcastFramesRxOK ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggBroadcastFramesRxOK;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggBroadcastFramesRxOK(124);

bAggBroadcastFramesRxOK BEHAVIOUR



aAggFramesDiscardedOnTx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesDiscardedOnTx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesDiscardedOnTx(125);

bAggFramesDiscardedOnTx BEHAVIOUR





aAggFramesDiscardedOnRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesDiscardedOnRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesDiscardedOnRx(126);

bAggFramesDiscardedOnRx BEHAVIOUR



aAggFramesWithTxErrors ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesWithTxErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesWithTxErrors(127);

bAggFramesWithTxErrors BEHAVIOUR



aAggFramesWithRxErrors ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggFramesWithRxErrors;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggFramesWithRxErrors(128);

bAggFramesWithRxErrors BEHAVIOUR



aAggUnknownProtocolFrames ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggUnknownProtocolFrames;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggUnknownProtocolFrames(129);



bAggUnknownProtocolFrames BEHAVIOUR



aAggLinkUpDownNotificationEnable ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.NotificationEnable;MATCHES FOR EQUALITY;BEHAVIOUR bAggLinkUpDownNotificationEnable;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggLinkUpDownNotificationEnable(130);

bAggLinkUpDownNotificationEnable BEHAVIOUR


aAggPortList ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortList;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortList;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortList(131);

bAggPortList BEHAVIOUR


aAggCollectorMaxDelay ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.CollectorMaxDelay;MATCHES FOR EQUALITY;BEHAVIOUR bAggCollectorMaxDelay;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggCollectorMaxDelay(132);

bAggCollectorMaxDelay BEHAVIOUR


30A.11.3 Aggregator notifications

nAggLinkUpNotification NOTIFICATION

BEHAVIOUR bAggLinkUpNotification;WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.AggID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) notifica-

tion(10) nAggLinkUpNotification(6);



bAggLinkUpNotification BEHAVIOUR


nAggLinkDownNotification NOTIFICATION

BEHAVIOUR bAggLinkDownNotification;WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) notifica-

tion(10) nAggLinkDownNotification(7);

bAggLinkDownNotification BEHAVIOUR


30A.12 Aggregation Port managed object class

30A.12.1 Aggregation Port, formal definition

oAggregationPort MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;CHARACTERIZED BY

pAggregationPortBasic PACKAGEATTRIBUTES aAggPortID GET;


pAggregationPortMandatory PACKAGEATTRIBUTES aAggPortActorSystemPriority GET-REPLACE,

aAggPortActorSystemID GET,aAggPortActorAdminKey GET-REPLACE,aAggPortActorOperKey GET,aAggPortPartnerAdminSystemPriority GET-REPLACE,aAggPortPartnerOperSystemPriority GET,aAggPortPartnerAdminSystemID GET-REPLACE,aAggPortPartnerOperSystemID GET,aAggPortPartnerAdminKey GET-REPLACE,aAggPortPartnerOperKey GET,aAggPortSelectedAggID GET,aAggPortAttachedAggID GET,aAggPortActorPort GET,aAggPortActorPortPriority GET-REPLACE,aAggPortPartnerAdminPort GET-REPLACE,aAggPortPartnerOperPort GET,aAggPortPartnerAdminPortPriority GET-REPLACE,aAggPortPartnerOperPortPriority GET,aAggPortActorAdminState GET-REPLACE,aAggPortActorOperState GET,aAggPortPartnerAdminState GET-REPLACE,aAggPortPartnerOperState GET,aAggPortAggregateOrIndividual GET;




mgt(30) package(4) pAggregationPortMandatory(22);PRESENT IF Conformance to Link Aggregation management is desired;


jectClass(3) oAggregationPort(11);

nbAggregationPort NAME BINDING

SUBORDINATE OBJECT CLASS oAggregationPort;NAMED BY SUPERIOR OBJECT CLASS oAggregator;WITH ATTRIBUTE aAggPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbAggregationPortName(21);

30A.12.2 Aggregation Port attributes

aAggPortID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortID;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortID(133);

bAggPortID BEHAVIOUR


aAggPortActorSystemPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortActorSystemPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorSystemPriority(134);

bAggPortActorSystemPriority BEHAVIOUR


aAggPortActorSystemID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortActorSystemID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorSystemID(135);

bAggPortActorSystemID BEHAVIOUR




aAggPortActorAdminKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortActorAdminKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorAdminKey(136);

bAggPortActorAdminKey BEHAVIOUR


aAggPortActorOperKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortActorOperKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorOperKey(137);

bAggPortActorOperKey BEHAVIOUR


aAggPortPartnerAdminSystemPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerAdminSystemPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerAdminSystemPriority(138);

bAggPortPartnerAdminSystemPriority BEHAVIOUR


aAggPortPartnerOperSystemPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerOperSystemPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerOperSystemPriority(139);

bAggPortPartnerOperSystemPriority BEHAVIOUR


aAggPortPartnerAdminSystemID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerAdminSystemID;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)aAggPortPartnerAdminSystemID(140);

bAggPortPartnerAdminSystemID BEHAVIOUR


aAggPortPartnerOperSystemID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR baAggPortPartnerOperSystemID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerOperSystemID(141);

bAggPortPartnerOperSystemID BEHAVIOUR


aAggPortPartnerAdminKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortPartnerAdminKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerAdminKey(142);

bAggPortPartnerAdminKey BEHAVIOUR


aAggPortPartnerOperKey ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.KeyValue;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortPartnerOperKey;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerOperKey(143);

bAggPortPartnerOperKey BEHAVIOUR


aAggPortSelectedAggID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggID;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortSelectedAggID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortSelectedAggID(144);

bAggPortSelectedAggID BEHAVIOUR




aAggPortAttachedAggID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggID;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortAttachedAggID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortAttachedAggID(145);

bAggPortAttachedAggID BEHAVIOUR


aAggPortActorPort ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortNumber;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortActorPort;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorPort(146);

bAggPortActorPort BEHAVIOUR


aAggPortActorPortPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortActorPortPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorPortPriority(147);

bAggPortActorPortPriority BEHAVIOUR


aAggPortPartnerAdminPort ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortNumber;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerAdminPort;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerAdminPort(148);

bAggPortPartnerAdminPort BEHAVIOUR


aAggPortPartnerOperPort ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortNumber;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerOperPort;



REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)aAggPortPartnerOperPort(149);

bAggPortPartnerOperPort BEHAVIOUR


aAggPortPartnerAdminPortPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerAdminPortPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerAdminPortPriority(150);

bAggPortPartnerAdminPortPriority BEHAVIOUR


aAggPortPartnerOperPortPriority ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PriorityValue;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerOperPortPriority;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerOperPortPriority(151);

bAggPortPartnerOperPortPriority BEHAVIOUR


aAggPortActorAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortActorAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorAdminState(152);

bAggPortActorAdminState BEHAVIOUR


aAggPortActorOperState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortActorOperState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortActorOperState(153);

bAggPortActorOperState BEHAVIOUR




aAggPortPartnerAdminState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortState;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerAdminState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerAdminState(154);

bAggPortPartnerAdminState BEHAVIOUR


aAggPortPartnerOperState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortState;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortPartnerOperState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortPartnerOperState(155);

bAggPortPartnerOperState BEHAVIOUR


aAggPortAggregateOrIndividual ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggOrInd;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortAggregateOrIndividual;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortAggregateOrIndividual(156);

bAggPortAggregateOrIndividual BEHAVIOUR


30A.13 Aggregation Port Statistics managed object class

30A.13.1 Aggregation Port Statistics, formal definition

oAggPortStats MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;CONDITIONAL PACKAGES

pAggPortStats PACKAGEATTRIBUTES aAggPortStatsID GET,

aAggPortStatsLACPDUsRx GET,aAggPortStatsMarkerPDUsRx GET,aAggPortStatsMarkerResponsePDUsRx GET,aAggPortStatsUnknownRx GET,aAggPortStatsIllegalRx GET,aAggPortStatsLACPDUsTx GET,



aAggPortStatsMarkerPDUsTx GET,aAggPortStatsMarkerResponsePDUsTx GET;


mgt(30) package(4) pAggPortStats(23);PRESENT IF The Aggregation Port Statistics package is supported;


jectClass(3) oAggPortStats(12);

nbAggPortStats NAME BINDING

SUBORDINATE OBJECT CLASS oAggPortStats;NAMED BY SUPERIOR OBJECT CLASS oAggregationPort;WITH ATTRIBUTE aAggPortStatsID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbAggPortStats(22);

30A.13.2 Aggregation Port Statistics attributes

aAggPortStatsID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortID;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortStatsID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsID(157);

bAggPortStatsID BEHAVIOUR


aAggPortStatsLACPDUsRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsLACPDUsRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsLACPDUsRx(158);

bAggPortStatsLACPDUsRx BEHAVIOUR


NOTE—This counter has a maximum increment rate of 5 counts per second at 10 Mb/s.;

aAggPortStatsMarkerPDUsRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsMarkerPDUsRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsMarkerPDUsRx(159);



bAggPortStatsMarkerPDUsRx BEHAVIOUR



aAggPortStatsMarkerResponsePDUsRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsMarkerResponsePDUsRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsMarkerResponsePDUsRx(160);

bAggPortStatsMarkerResponsePDUsRx BEHAVIOUR



aAggPortStatsUnknownRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsUnknownRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsUnknownRx(161);

bAggPortStatsUnknownRx BEHAVIOUR



aAggPortStatsIllegalRx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsIllegalRx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsIllegalRx(162);

bAggPortStatsIllegalRx BEHAVIOUR



aAggPortStatsLACPDUsTx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsLACPDUsTx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsLACPDUsTx(163);



bAggPortStatsLACPDUsTx BEHAVIOUR



aAggPortStatsMarkerPDUsTx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsMarkerPDUsTx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsMarkerPDUsTx(164);

bAggPortStatsMarkerPDUsTx BEHAVIOUR



aAggPortStatsMarkerResponsePDUsTx ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortStatsMarkerResponsePDUsTx;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortStatsMarkerResponsePDUsTx(165);

bAggPortStatsMarkerResponsePDUsTx BEHAVIOUR



30A.14 Aggregation Port Debug Information managed object class

30A.14.1 Aggregation Port Debug Information, formal definition

oAggPortDebugInformation MANAGED OBJECT CLASS

DERIVED FROM “CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992”:top;CONDITIONAL PACKAGES

pLACPDebug PACKAGEATTRIBUTES aAggPortDebugInformationID GET,

aAggPortDebugRxState GET,aAggPortDebugLastRxTime GET,aAggPortDebugMuxState GET,aAggPortDebugMuxReason GET,aAggPortDebugActorChurnState GET,aAggPortDebugPartnerChurnState GET,aAggPortDebugActorChurnCount GET,aAggPortDebugPartnerChurnCount GET,aAggPortDebugActorSyncTransitionCount GET,aAggPortDebugPartnerSyncTransitionCount GET,



aAggPortDebugActorChangeCount GET,aAggPortDebugPartnerChangeCount GET;


mgt(30) package(4) pAggPortDebugInformation(24);PRESENT IF The Aggregation Port Debug Information package is sup-ported;


jectClass(3) oAggPortDebugInformation(13);

nbAggPortDebugInformation NAME BINDING

SUBORDINATE OBJECT CLASS oAggPortDebugInformation;NAMED BY SUPERIOR OBJECT CLASS oAggregationPort;WITH ATTRIBUTE aAggPortDebugInformationIDREGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) nameBind-

ing(6) nbAggPortDebugInformation(23);

30A.14.2 Aggregation Port Debug Information attributes

aAggPortDebugInformationID ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.AggPortID;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugInformationID;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugInformationID(166);

bAggPortDebugInformationID BEHAVIOUR


aAggPortDebugRxState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.RxState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortDebugRxState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugRxState(167);

bAggPortDebugRxState BEHAVIOUR


aAggPortDebugLastRxTime ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugLastRxTime;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugLastRxTime(168);



bAggPortDebugLastRxTime BEHAVIOUR


aAggPortDebugMuxState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MuxState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortDebugMuxState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugMuxState(169);

bAggPortDebugMuxState BEHAVIOUR


aAggPortDebugMuxReason ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.DescriptionString;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortDebugMuxReason;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugMuxReason(170);

bAggPortDebugMuxReason BEHAVIOUR


aAggPortDebugActorChurnState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.ChurnState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortDebugActorChurnState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugActorChurnState(171);

bAggPortDebugActorChurnState BEHAVIOUR


aAggPortDebugPartnerChurnState ATTRIBUTE

WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.ChurnState;MATCHES FOR EQUALITY;BEHAVIOUR bAggPortDebugPartnerChurnState;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugPartnerChurnState(172);

bAggPortDebugPartnerChurnState BEHAVIOUR




aAggPortDebugActorChurnCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugActorChurnCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugActorChurnCount(173);

bAggPortDebugActorChurnCount BEHAVIOUR


NOTE—This counter has a maximum increment rate of 5 counts per second.;

aAggPortDebugPartnerChurnCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugPartnerChurnCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugPartnerChurnCount(174);

bAggPortDebugPartnerChurnCount BEHAVIOUR



aAggPortDebugActorSyncTransitionCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugActorSyncTransitionCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugActorSyncTransitionCount(175);

bAggPortDebugActorSyncTransitionCount BEHAVIOUR



aAggPortDebugPartnerSyncTransitionCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugPartnerSyncTransitionCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugPartnerSyncTransitionCount(176);

bAggPortDebugPartnerSyncTransitionCount BEHAVIOUR





aAggPortDebugActorChangeCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugActorChangeCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugActorChangeCount(177);

bAggPortDebugActorChangeCount BEHAVIOUR



aAggPortDebugPartnerChangeCount ATTRIBUTE

DERIVED FROM aCMCounter;MATCHES FOR EQUALITY, ORDERING;BEHAVIOUR bAggPortDebugPartnerChangeCount;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30) attribute(7)

aAggPortDebugPartnerChangeCount(178);

bAggPortDebugPartnerChangeCount BEHAVIOUR





Annex 30B

(normative)

GDMO and ASN.1 definitions for management

30B.1 Common attributes template

This template defines generic facilities that are used in the standard.

aCMCounter ATTRIBUTE

DERIVED FROM “ISO/IEC 10165-5”:genericWrappingCounter;BEHAVIOUR bCMCounter;REGISTERED AS iso(1) member-body(2) us(840) 802dot3(10006) csmacdmgt(30)

attribute(7) cmCounter(88);

bCMCounter BEHAVIOUR

DEFINED AS Wraps at one of two sizes. Size is conditional.Wraps at 32 bits, that is this counter reaches its maximum value at 232–1 (i.e., approximately 4.294 × 109) and then rolls over to zero on the next increment, if maximum increment rate from zero causes a rollover in 58 min or more.Wraps at 64 bits, that is this counter reaches its maximum value at 264–1 (i.e., approximately 1.844... × 1019) and then rolls over to zero on the next increment, if maximum increment rate from zero would cause a 32 bit counter to roll over in less than 58 min.The counter that this is derived from initializes to zero. Initialization to zero is not a requirement of this standard;

30B.2 ASN.1 module for CSMA/CD managed objects

This ASN.1 module defines the ASN.1 types and subtypes that are referred to immediately after theWITH ATTRIBUTE SYNTAX construct in this clause’s uses of the attribute template defined in ISO/IEC 10165-4: 1992, Guidelines for the definition of managed objects (GDMO).

IEEE802Dot3-MgmtAttributeModule iso(1) member-body(2) us(840) 802dot3(10006) global(1)asn1Module(2) commonDefinitions(0) version(2) DEFINITIONS IMPLICIT TAGS::= BEGIN

EXPORTS--everything

IMPORTS--implicitly imports ISO 8824: 1990

MACAddressFROM IEEE802CommonDefinitionsiso(1) member-body(2) us(840) ieee802dot1partF(10011) asn1Module(2) commonDefinitions(0) version1(0);

AdminState::= ENUMERATED other (1), --undefined



unknown (2), --initializing, true state not yet knownoperational (3), --powered and connectedstandby (4), --inactive but onshutdown (5) --similar to power down

AggDataRate ::= INTEGER (0..2^32-1)--The data rate of an Aggregation

AggID ::= INTEGER (0..2^32-1)

AggOrInd ::= BOOLEAN

AggPortID ::= INTEGER (0..2^32-1)

AggPortList ::= SEQUENCE OF AggPortID

AggPortState ::= BIT STRING (SIZE (1..8))

AggState ::= ENUMERATED up (0), --operationaldown (1) --disabled

AttemptArray::= SEQUENCE OF aCMCounter--array [1..attempt limit - 1]

AutoNegAdminState::= ENUMERATED disabled (1),enabled (2)

AutoNegAutoConfig::= ENUMERATED other (1),configuring (2),complete (3),disabled (4),parallel detect fail (5)

AutoNegRemoteSignalingDetect::= ENUMERATED detected (1),notdetected (2)

AutoNegSelector::= ENUMERATED other (1), --undefinedethernet (2), --802.3isoethernet (3) --802.9

AutoNegSelectorList::= SEQUENCE OF AutoNegSelector

AutoNegTechnology::= ENUMERATED



global (0), --reserved for future use.other (1), --undefinedunknown (2), --initializing, true ability not yet known.10BASE-T (14), --10BASE-T as defined in Clause 1410BASE-TFD (142), --Full duplex 10BASE-T as defined in Clauses 14 and 31100BASE-T4 (23), --100BASE-T4 as defined in Clause 23100BASE-TX (25), --100BASE-TX as defined in Clause 25100BASE-TXFD (252), --Full duplex 100BASE-TX as defined in Clauses 25 and 31FDX PAUSE (312), --PAUSE operation for full duplex links as defined in Annex 31BFDX APAUSE (313), --Asymmetric PAUSE operation for full duplex links as defined

in Clause 37 and Annex 31BFDX SPAUSE (314), --Symmetric PAUSE operation for full duplex links as defined

in Clause 37 and Annex 31BFDX BPAUSE (315), --Asymmetric and Symmetric PAUSE operation for full duplex

links as defined in Clause 37 and Annex 31B100BASE-T2 (32), --100BASE-T2 as defined in Clause 32100BASE-T2FD (322), --Full duplex 100BASE-T2 as defined in Clauses 31 and 321000BASE-X (36), --1000BASE-X as defined in Clause 361000BASE-XFD (362), --Full duplex 1000BASE-X as defined in Clause 361000BASE-T (40), --1000BASE-T UTP PHY as defined in Clause 401000BASE-TFD (402), --Full duplex 1000BASE-T UTP PHY to be defined in Clause 40Rem Fault1 (37), --Remote fault bit 1 (RF1) as specified in Clause 37Rem Fault2 (372), --Remote fault bit 2 (RF1) as specified in Clause 37isoethernet (8029) --802.9 ISLAN-16T

AutoNegTechnologyList::= SEQUENCE OF AutoNegTechnology

AutoPartitionState::= ENUMERATED autoPartitioned (1),notAutoPartitioned (2)

BbandFrequency::= SEQUENCE xmitCarrierFrequency [1] INTEGER , --Frequency in MHz times 4 (250 kHz resolution)translationFrequency [2] INTEGER --Frequency in MHz times 4 (250 kHz resolution)

BbandXmitRcvSplitType::= ENUMERATED other (1), --undefinedsingle (2), --single-cable systemdual (3) --dual-cable system, offset normally zero

BitString::= BIT STRING (SIZE (1..1024))

ChurnState ::= ENUMERATED noChurn (0), --NO_ACTOR/PARTNER_CHURN

--or ACTOR/PARTNER_CHURN_MONITORchurn (1) --ACTOR/PARTNER_CHURN

CollectorMaxDelay ::= INTEGER --16 bit value, tens of microseconds--(max = 0.65535 seconds)

DescriptionString ::= PrintableString (SIZE 0..255))



DuplexValues::= ENUMERATED half duplex (1), --capable of operating in half duplex modefull duplex (2), --capable of operating in full duplex modeunknown (3) --unknown duplex capability

Integer32 ::= INTEGER (0..2^32-1) --32 bit value

Jabber::= SEQUENCE jabberFlag [1] JabberFlag,jabberCounter [2] JabberCounter

JabberFlag::= ENUMERATED other (1), --undefinedunknown (2), --initializing, true state not yet knownnormal (3), --state is true or normalfault (4) --state is false, fault or abnormal

JabberCounter::= INTEGER (0..232 –1)

KeyValue ::= INTEGER (0..2^16-1) --16 bit value; range 0-65535

LACPActivity ::= ENUMERATED active (0), --Port is Active LACPpassive (1) --Port is Passive LACP

LACPTimeout ::= ENUMERATED short (0), --Timeouts are Shortlong (1) --Timeouts are Long

LinkDelayAllowance::= INTEGER (0..232–1)

MACControlFunctions::= ENUMERATED PAUSE (312) --PAUSE command implemented

MACControlFunctionsList::= SEQUENCE OF MACControlFunctions

MACCapabilitiesList::= SEQUENCE OF DuplexValues

MauTypeList::= SEQUENCE OF TypeValue

MediaAvailState::= ENUMERATED other (1), --undefinedunknown (2), --initializing, true state not yet knownavailable (3), --link or light normal, loopback normalnot available (4), --link loss or low light, no loopback



remote fault (5), --remote fault with no detailinvalid signal (6), --invalid signal, applies only to 10BASE-FBremote jabber (7), --remote fault, reason known to be jabberremote link loss (8), --remote fault, reason known to be far-end link lossremote test (9), --remote fault, reason known to be testoffline (10), --offline, applies only to Clause 37 Auto-Negotiationauto neg error (11) --Auto-Negotiation error, applies only to Clause 37 Auto-

Negotiation

MIIDetect::= ENUMERATED unknown (1),presentNothingConnected(2),presentConnected (3),absent (4)

MulticastAddressList::= SEQUENCE OF MACAddress

MuxState ::= ENUMERATED detached (0), --DETACHEDwaiting (1), --WAITINGattached (2), --ATTACHEDcollecting (3), --COLLECTINGdistributing (4), --DISTRIBUTINGcollecting_distributing (5) --COLLECTING_DISTRIBUTING

NotificationEnable ::= ENUMERATED enabled (0), --Notifications enableddisabled (1) --Notifications disabled

OneOfName::= INTEGER (1..1024)

PhyTypeList::= SEQUENCE OF PhyTypeValue

PhyTypeValue::= ENUMERATED other (1), --undefined unknown (2), --initializing, true state or type not yet knownnone (3), --MII present and nothing connected10 Mb/s (7), --Clause 7 10 Mb/s Manchester100BASE-T4 (23), --Clause 23 100 Mb/s 8B/6T100BASE-X (24), --Clause 24 100 Mb/s 4B/5B100BASE-T2 (32), --Clause 32 100 Mb/s PAM5x51000BASE-X (36), --Clause 36 1000 Mb/s 8B/10B1000BASE-T (40) --Clause 40 1000 Mb/s 4D-PAM5

PortAdminState::= ENUMERATED disabled (1),enabled (2)

PortNumber ::= INTEGER (0..2^16-1)



PriorityValue ::= INTEGER (0..2^16-1) --16 bits

RegisterEight::= INTEGER (0..255)

RepeaterHealthData::= OCTET STRING (SIZE (0..255))

RepeaterHealthInfo::= SEQUENCE repeaterHealthState [1] RepeaterHealthState,repeaterHealthText [2] RepeaterHealthText OPTIONAL,repeaterHealthData [3] RepeaterHealthData OPTIONAL

RepeaterHealthState::= ENUMERATED other (1), --undefined or unknownok (2), --no known failuresrepeaterFailure (3), --known to have a repeater-related failuregroupFailure (4), --known to have a group-related failureportFailure (5), --known to have a port-related failuregeneralFailure (6) --has a failure condition, unspecified type

RepeaterType::= ENUMERATED other (1), --See 30.2.5: unknown (2), --initializing, true state or type not yet known10 Mb/s (9), --Clause 9 10 Mb/s Baseband repeater100 Mb/sClassI (271), --Clause 27 class I 100 Mb/s Baseband repeater100 Mb/sClassII (272), --Clause 27 class II 100 Mb/s Baseband repeater1000 Mb/s (41), --Clause 41 1000 Mb/s Baseband repeater802.9a (99) --Integrated services repeater

RepeaterHealthText::= PrintableString (SIZE (0..255))

RxState ::= ENUMERATED current (0),expired (1),defaulted (2),initialize (3),lacpDisabled (4),portDisabled (5)

TrueFalse::= BOOLEAN

TypeList::= SEQUENCE OF TypeValue

TypeValue::= ENUMERATED global (0), --undefinedother (1), --undefinedunknown (2), --initializing, true state not yet knownAUI (7), --no internal MAU, view from AUI10BASE5 (8), --Thick coax MAU as specified in Clause 8FOIRL (9), --FOIRL MAU as specified in 9.910BASE2 (10), --Thin coax MAU as specified in Clause 10



10BROAD36 (11), --Broadband DTE MAU as specified in Clause 1110BASE-T (14), --UTP MAU as specified in Clause 14, duplex mode

unknown10BASE-THD (141), --UTP MAU as specified in Clause 14, half duplex mode10BASE-TFD (142), --UTP MAU as specified in Clause 14, full duplex mode10BASE-FP (16), --Passive fiber MAU as specified in Clause 1610BASE-FB (17), --Synchronous fiber MAU as specified in Clause 1710BASE-FL (18), --Asynchronous fiber MAU as specified in Clause 18, duplex

mode unknown10BASE-FLHD (181), --Asynchronous fiber MAU as specified in Clause 18, half

duplex mode10BASE-FLFD (182), --Asynchronous fiber MAU as specified in Clause 18, full

duplex mode100BASE-T4 (23), --Four-pair Category 3 UTP as specified in Clause 23100BASE-TX (25), --Two-pair Category 5 UTP as specified in Clause 25, duplex

mode unknown100BASE-TXHD (251), --Two-pair Category 5 UTP as specified in Clause 25, half

duplex mode100BASE-TXFD (252), --Two-pair Category 5 UTP as specified in Clause 25, full

duplex mode100BASE-FX (26), --X fiber over PMD as specified in Clause 26, duplex mode

unknown100BASE-FXHD (261), --X fiber over PMD as specified in Clause 26, half duplex mode100BASE-FXFD (262), --X fiber over PMD as specified in Clause 26, full duplex mode100BASE-T2 (32), --Two-pair Category 3 UTP as specified in Clause 32, duplex

mode unknown100BASE-T2HD (321), --Two-pair Category 3 UTP as specified in Clause 32, half

duplex mode100BASE-T2FD (322), --Two-pair Category 3 UTP as specified in Clause 32, full

duplex mode1000BASE-X (36), --X PCS/PMA as specified in Clause 36 over unknown PMD,

duplex mode unknown1000BASE-XHD (361), --X PCS/PMA as specified in Clause 36 over unknown PMD,

half duplex mode1000BASE-XFD (362), --X PCS/PMA as specified in Clause 36 over unknown PMD,

full duplex mode1000BASE-LX (381), --X fiber over long-wavelength laser PMD as specified in

Clause 38, duplex mode unknown1000BASE-LXHD (382), --X fiber over long-wavelength laser PMD as specified in

Clause 38, half duplex mode1000BASE-LXFD (383), --X fiber over long-wavelength laser PMD as specified in

Clause 38, full duplex mode1000BASE-SX (384), --X fiber over short-wavelength laser PMD as specified in

Clause 38, duplex mode unknown1000BASE-SXHD (385), --X fiber over short-wavelength laser PMD as specified in

Clause 38, half duplex mode1000BASE-SXFD (386), --X fiber over short-wavelength laser PMD as specified in

Clause 38, full duplex mode1000BASE-CX (39), --X copper over 150-Ohm balanced cable PMD as specified in

Clause 39, duplex mode unknown1000BASE-CXHD (391), --X copper over 150-Ohm balanced cable PMD as specified in

Clause 39, half duplex mode1000BASE-CXFD (392), --X copper over 150-Ohm balanced cable PMD as specified in

Clause 39, full duplex mode1000BASE-T (40), --Four-pair Category 5 UTP PHY as specified in Clause 40,

duplex mode unknown1000BASE-THD (401), --Four-pair Category 5 UTP PHY as specified in Clause 40,

half duplex mode 1000BASE-TFD (402), --Four-pair Category 5 UTP PHY as specified in Clause 40,

full duplex mode 802.9a (99) --Integrated services MAU as specified in IEEE Std 802.9

ISLAN-16T

END



Annex 30C

(normative)

SNMP MIB definitions for Link Aggregation

30C.1 Introduction

This annex defines a portion of the Management Information Base (MIB) for use with network managementprotocols in TCP/IP based internets. In particular it defines objects for managing the operation of the LinkAggregation sublayer, based on the specification of Link Aggregation contained in Clause 43. This annexincludes an MIB module that is SNMPv2 SMI compliant.

30C.2 The SNMP Management Framework

The SNMP Management Framework presently consists of five major components

a) An overall architecture, described in RFC 2271.b) Mechanisms for describing and naming objects and events for the purpose of management. The first

version of this Structure of Management Information (SMI) is called SMIv1 and is described inRFC 1155, RFC 1212, and RFC 1215. The second version, called SMIv2, is described in RFC 1902,RFC 1903, and RFC 1904.

c) Message protocols for transferring management information. The first version of the SNMP mes-sage protocol is called SNMPv1 and is described in RFC 1157. A second version of the SNMP mes-sage protocol, which is not an Internet standards track protocol, is called SNMPv2c and is describedin RFC 1901 and RFC 1906. The third version of the message protocol is called SNMPv3 and isdescribed in RFC 1906, RFC 2272, and RFC 2274.

d) Protocol operations for accessing management information. The first set of protocol operations andassociated PDU formats is described in RFC 1157. A second set of protocol operations and associ-ated PDU formats is described in RFC 1905.

e) A set of fundamental applications described in RFC 2273 and the view-based access control mecha-nism described in RFC 2275.

Managed objects are accessed via a virtual information store, termed the Management Information Base orMIB. Objects in the MIB are defined using the mechanisms defined in the SMI.

This annex specifies an MIB module that is compliant to the SMIv2. An MIB conforming to the SMIv1 canbe produced through the appropriate translations. The resulting translated MIB must be semantically equiva-lent, except where objects or events are omitted because no translation is possible (use of Counter64). Somemachine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during thetranslation process. However, this loss of machine-readable information is not considered to change thesemantics of the MIB.

30C.3 Security considerations

There are a number of management objects defined in this MIB that have a MAX-ACCESS clause ofreadwrite and/or read-create. Such objects may be considered sensitive or vulnerable in some networkenvironments. The support for SET operations in a non-secure environment can have a negative effect onnetwork operations.



SNMPv1 by itself is not a secure environment. Even if the network itself is secure (e.g., by using IPSec),there is no control as to who on the secure network is allowed to access (read/change/create/delete) theobjects in this MIB.

It is recommended that the implementors consider the security features as provided by the SNMPv3 frame-work. Specifically, the use of the User-based Security Model RFC 2274 and the View-based Access ControlModel RFC 2275 is recommended. It then becomes a user responsibility to ensure that the SNMP entity giv-ing access to an instance of this MIB is properly configured to give access only to those principals (users)that have legitimate rights to access(read/change/create/delete) them, as appropriate.

30C.4 Structure of the MIB

A single MIB module is defined in this annex. Objects in the MIB are arranged into groups. Each group isorganized as a set of related objects. The overall structure and assignment of objects to their groups is shownin the following subclauses.

30C.4.1 Relationship to the managed objects defined in Clause 30

This subclause contains cross-references to the objects defined in Clause 30. Table 30C–1 contains cross ref-erences for the MIB objects defined in this annex. Table 30C–2 contains definitions of ifTable elements, asdefined in RFC 2233, for an Aggregator. These table elements are cross referenced to the corresponding def-initions in Clause 30.

Table 30C–1—Managed object cross reference table

Definition in Clause 30 MIB object

30.7.1.1.1 aAggID ifIndex value (see RFC 2233)

30.7.1.1.4 aAggActorSystemID dot3adAggActorSystemID

30.7.1.1.5 aAggActorSystemPriority dot3adAggActorSystemPriority

30.7.1.1.6 aAggAggregateOrIndividual dot3adAggAggregateOrIndividual

30.7.1.1.7 aAggActorAdminKey dot3adAggActorAdminKey

30.7.1.1.8 aAggActorOperKey dot3adAggActorOperKey

30.7.1.1.10 aAggPartnerSystemID dot3adAggPartnerSystemID

30.7.1.1.11 aAggPartnerSystemPriority dot3adAggPartnerSystemPriority

30.7.1.1.12 aAggPartnerOperKey dot3adAggPartnerOperKey

30.7.1.1.30 aAggPortList dot3adAggPortListTable

30.7.1.1.32 aAggCollectorMaxDelay dot3adAggCollectorMaxDelay

30.7.2.1.1 aAggPortID ifIndex value (see RFC 2233)

30.7.2.1.2 aAggPortActorSystemPriority dot3adAggPortActorSystemPriority



30.7.2.1.3 aAggPortActorSystemID dot3adAggPortActorSystemID

30.7.2.1.4 aAggPortActorAdminKey dot3adAggPortActorAdminKey

30.7.2.1.5 aAggPortActorOperKey dot3adAggPortActorOperKey

30.7.2.1.6 aAggPortPartnerAdminSystemPriority dot3adAggPortPartnerAdminSystemPriority

30.7.2.1.7 aAggPortPartnerOperSystemPriority dot3adAggPortPartnerOperSystemPriority

30.7.2.1.8 aAggPortPartnerAdminSystemID dot3adAggPortPartnerAdminSystemID

30.7.2.1.9 aAggPortPartnerOperSystemID dot3adAggPortPartnerOperSystemID

30.7.2.1.10 aAggPortPartnerAdminKey dot3adAggPortPartnerAdminKey

30.7.2.1.11 aAggPortPartnerOperKey dot3adAggPortPartnerOperKey

30.7.2.1.12 aAggPortSelectedAggID dot3adAggPortSelectedAggID

30.7.2.1.13 aAggPortAttachedAggID dot3adAggPortAttachedAggID

30.7.2.1.14 aAggPortActorPort dot3adAggPortActorPort

30.7.2.1.15 aAggPortActorPortPriority dot3adAggPortActorPortPriority

30.7.2.1.16 aAggPortPartnerAdminPort dot3adAggPortPartnerAdminPort

30.7.2.1.17 aAggPortPartnerOperPort dot3adAggPortPartnerOperPort

30.7.2.1.18 aAggPortPartnerAdminPortPriority dot3adAggPortPartnerAdminPortPriority

30.7.2.1.19 aAggPortPartnerOperPortPriority dot3adAggPortPartnerOperPortPriority

30.7.2.1.20 aAggPortActorAdminState dot3adAggPortActorAdminState

30.7.2.1.21 aAggPortActorOperState dot3adAggPortActorOperState

30.7.2.1.22 aAggPortPartnerAdminState dot3adAggPortPartnerAdminState

30.7.2.1.23 aAggPortPartnerOperState dot3adAggPortPartnerOperState

30.7.2.1.24 aAggPortAggregateOrIndividual dot3adAggPortAggregateOrIndividual

30.7.3.1.1 aAggPortStatsID ifIndex value (see RFC 2233) of the port

30.7.3.1.2 aAggPortStatsLACPDUsRx dot3adAggPortStatsLACPDUsRx

30.7.3.1.3 aAggPortStatsMarkerPDUsRx dot3adAggPortStatsMarkerPDUsRx

30.7.3.1.4 aAggPortStatsMarkerResponsePDUsRx dot3adAggPortStatsMarkerResponsePDUsRx

30.7.3.1.5 aAggPortStatsUnknownRx dot3adAggPortStatsUnknownRx

Table 30C–1—Managed object cross reference table (continued)




30C.4.2 The Aggregator Group

This group of objects, in combination with the ifTable entry for an Aggregator and the Aggregator Port List,provides the functionality of the Aggregator managed object class (30.7.1). The Aggregator Group providesthe control elements necessary to configure an Aggregator, plus the statistical information necessary to mon-itor the behaviour of an Aggregator.

30C.4.3 The Aggregator Port List Group

This group of objects implements the functionality defined for the Aggregator Port List attribute(30.7.1.1.30).

30.7.3.1.6 aAggPortStatsIllegalRx dot3adAggPortStatsIllegalRx

30.7.3.1.7 aAggPortStatsLACPDUsTx dot3adAggPortStatsLACPDUsTx

30.7.3.1.8 aAggPortStatsMarkerPDUsTx dot3adAggPortStatsMarkerPDUsTx

30.7.3.1.9 aAggPortStatsMarkerResponsePDUsTx dot3adAggPortStatsMarkerResponsePDUsTx

30.7.4.1.1 aAggPortDebugInformationID ifIndex value (see RFC 2233) of the port

30.7.4.1.2 aAggPortDebugRxState dot3adAggPortDebugRxState

30.7.4.1.3 aAggPortDebugLastRxTime dot3adAggPortDebugLastRxTime

30.7.4.1.4 aAggPortDebugMuxState dot3adAggPortDebugMuxState

30.7.4.1.5 aAggPortDebugMuxReason dot3adAggPortDebugMuxReason

30.7.4.1.6 aAggPortDebugActorChurnState dot3adAggPortDebugActorChurnState

30.7.4.1.7 aAggPortDebugPartnerChurnState dot3adAggPortDebugPartnerChurnState

30.7.4.1.8 aAggPortDebugActorChurnCount dot3adAggPortDebugActorChurnCount

30.7.4.1.9 aAggPortDebugPartnerChurnCount dot3adAggPortDebugPartnerChurnCount

30.7.4.1.10 aAggPortDebugActorSyncTransitionCount dot3adAggPortDebugActorSyncTransitionCount

30.7.4.1.11 aAggPortDebugPartnerSyncTransitionCount dot3adAggPortDebugPartnerSyncTransitionCount

30.7.4.1.12 aAggPortDebugActorChangeCount dot3adAggPortDebugActorChangeCount

30.7.4.1.13 aAggPortDebugPartnerChangeCount dot3adAggPortDebugPartnerChangeCount

Table 30C–1—Managed object cross reference table (continued)




Table 30C–2—ifTable element definitions for an Aggregator

Object Definition

ifIndex A unique integer value is allocated to each Aggregator by the local System. Interpreted as defined in RFC 2233.

ifDescr Interpreted as defined in RFC 2233 and as further refined in the definition of aAggDescription (30.7.1.1.2).

ifType ieee8023adLag(161)a.

ifMTU The largest MAC Client SDU that can be carried by this Aggregator—1500 octets.

ifSpeed The data rate of the Aggregation as defined for aAggDataRate (30.7.1.1.16).

ifPhysAddress The individual MAC Address of the Aggregator as defined for aAggMACAd-dress (30.7.1.1.9).

ifAdminStatus The administrative state of the Aggregator as defined for aAggAdminState (30.7.1.1.13).

ifOperStatus The operational state of the Aggregator as defined for aAggOperState (30.7.1.1.14).

ifLastChange Interpreted as defined in RFC 2233; see also the definition ofaAggTimeOfLastOperChange (30.7.1.1.15).

ifInOctets The total number of user data octets received by the aggregation, as defined for aAggOctetsRxOK (30.7.1.1.18).

ifInUcastPkts The total number of unicast user data frames received by the aggregation. This value is calculated as the value of aAggFramesRxOK (30.7.1.1.20), less the val-ues of aAggMulticastFramesRxOK (30.7.1.1.22) and aAggBroadcastFrames-RxOK (30.7.1.1.24).

ifInNUcastPkts Deprecated in RFC 2233.

ifInDiscards The number of frames discarded on reception, as defined for aAggFramesDis-cardedOnRx (30.7.1.1.26).

ifInErrors The number of frames with reception errors, as defined for aAggFramesWith-RxErrors (30.7.1.1.28).

ifInUnknownProtos The number of unknown protocol frames discarded on reception, as defined for aAggUnknownProtocolFrames (30.7.1.1.29).

ifOutOctets The total number of user data octets transmitted by the aggregation, as defined for aAggOctetsTxOK (30.7.1.1.17).

ifOutUcastPkts The total number of unicast user data frames transmitted by the aggregation. This value is calculated as the value of aAggFramesTxOK (30.7.1.1.19), less the values of aAggMulticastFramesTxOK (30.7.1.1.21) and aAggBroadcast-FramesTxOK (30.7.1.1.23).

ifOutNUcastPkts Deprecated in RFC 2233.



30C.4.4 The Aggregation Port Group

This group of objects provides the functionality of the Aggregation Port managed object class (30.7.2). TheAggregation Port Group provides the control elements necessary to configure a Port for Link Aggregation,plus the statistical information necessary to monitor the behavior of the port.

30C.4.5 The Aggregation Port Statistics Group

This group of objects provides the functionality of the Aggregation Port Statistics managed object class(30.7.3). The Aggregation Port Statistics Group provides additional statistical information related to LACPand Marker protocol activity on the port.

30C.4.6 The Aggregation Port Debug Group

This group of objects provides the functionality of the Aggregation Port Debug managed object class(30.7.4). The Aggregation Port Debug Group provides additional information related to the operation ofLACP on the port; this information is primarily aimed at debugging the operation of the protocol and detect-ing fault conditions.

ifOutDiscards The number of frames discarded on transmission, as defined for aAggFrames-DiscardedOnTx (30.7.1.1.25).

ifOutErrors The number of frames discarded due to transmission errors, as defined for aAggFramesWithTxErrors (30.7.1.1.27).

ifOutQLen Deprecated in RFC 2233. Set to zero if present.

ifSpecific Deprecated in RFC 2233. Set to 0.0 if present.

ifLinkUpDownTrapEnable See the definition of aAggLinkUpDownNotificationEnable (30.7.1.1.31).

ifConnectorPresent “FALSE.”

ifHighSpeed Set to zero.

ifName The locally assigned textual name of the Aggregator, as defined for aAggName (30.7.1.1.3). Interpreted as defined in RFC 2233.

linkUp TRAP See the definition of nAggLinkUpNotification (30.7.1.2.1).

linkDown TRAP See the definition of nAggLinkDownNotification (30.7.1.2.2).

aValues of ifType are assigned by the Internet Assigned Numbers Authority (IANA). A directory of number assign-ments is maintained on their website, at URL: http://www.iana.org/numbers.html. The currently assigned ifTypevalues can be found in the SMI Numbers (Network Management Parameters) section of that directory.

Table 30C–2—ifTable element definitions for an Aggregator (continued)

Object Definition



30C.5 Relationship to other MIBs

It is assumed that a system implementing this MIB will also implement (at least) the “system” group definedin MIB-II defined in RFC 1213 and the “interfaces” group defined in RFC 2233.

30C.5.1 Relationship to the Interfaces MIB

RFC 2233, the Interface MIB Evolution, requires that any MIB that is an adjunct of the Interface MIB, clar-ify specific areas within the Interface MIB. These areas were intentionally left vague in RFC 2233 to avoidover constraining the MIB, thereby precluding management of certain media types.

Section 3.3 of RFC 2233 enumerates several areas that a media-specific MIB must clarify. Each of theseareas is addressed in 30C.5.2 and 30C.5.3. The implementor is referred to RFC 2233 in order to understandthe general intent of these areas.

In RFC 2233, the “interfaces” group is defined as being mandatory for all systems and contains informationon an entity’s interfaces, where each interface is thought of as being attached to a subnetwork. (Note that thisterm is not to be confused with subnet, which refers to an addressing partitioning scheme used in the Internetsuite of protocols.) The term segment is sometimes used to refer to such a subnetwork.

Implicit in this MIB is the notion of Aggregators and Aggregation ports. Each of these Aggregators andAggregation ports is associated with one interface of the “interfaces” group (one row in the ifTable) and eachport is associated with a different interface.

Each Aggregator and Aggregation port is uniquely identified by an interface number (ifIndex). The ifIndexvalue assigned to a given Aggregation port is the same as the ifIndex value assigned to the MAC interfacewith which that Aggregation port is associated.

30C.5.2 Layering model

This annex assumes the interpretation of the Interfaces Group to be in accordance with RFC 2233, whichstates that the ifTable contains information on the managed resource’s interfaces and that each sublayerbelow the internetwork layer of a network interface is considered an interface.

This annex recommends that, within an entity, aggregations that are instantiated as an entry indot3adAggTable are also represented by an entry in ifTable.

Where an entity contains Link Aggregation entities that transmit and receive traffic to/from an aggregation,these should be represented in the ifTable as interfaces of type ieee8023adLag(161).

30C.5.3 ifStackTable

If the ifStackTable defined in RFC1573 is implemented, then

a) The relationship shown in the table has the property that an Aggregation is a higher interface relativeto an Aggregation Port.

b) This relationship is read-only.

NOTE—The restriction stated here is intended to enforce a strict hierarchical relationship between Aggregations andAggregation Ports, and to prevent those relationships from being modified. The read-only restriction does not apply toany other relationships that may be expressed in the ifStackTable.



30C.5.4 ifRcvAddressTable

The ifRcvAddressTable contains all MAC Addresses, unicast, multicast, and broadcast, for which an inter-face can receive packets and forward them up to a higher layer entity for local consumption. An Aggregatorhas at least one such address.

30C.6 Definitions for Link Aggregation MIB

In the MIB definition below, should there be any discrepancy between the DESCRIPTION text and theBEHAVIOUR DEFINED AS in the corresponding definition in Clause 30, the definition in Clause 30 shalltake precedence.

LAG-MIB DEFINITIONS ::= BEGIN

-- --------------------------------------------------------------- IEEE 802.3ad MIB-- -------------------------------------------------------------

IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, TimeTicks, BITS FROM SNMPv2-SMI DisplayString, MacAddress, TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB PortList FROM Q-BRIDGE-MIB ;

lagMIB MODULE-IDENTITY LAST-UPDATED “9911220000Z” ORGANIZATION “IEEE 802.3ad Working Group” CONTACT-INFO “ [email protected]” DESCRIPTION “The Link Aggregation module for managing IEEE 802.3ad.” ::= iso(1) member-body(2) us(840) 802dot3(10006) snmpmibs(300) linkagg(43)

lagMIBObjects OBJECT IDENTIFIER ::= lagMIB 1

-- --------------------------------------------------------------- Textual Conventions-- -------------------------------------------------------------



LacpKey ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION “The Actor or Partner Key value.” SYNTAX INTEGER (0..65535)

LacpState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION “The Actor and Partner State values from the LACPDU.” SYNTAX BITS

lacpActivity(0),lacpTimeout(1),aggregation(2),synchronization(3),collecting(4),distributing(5),defaulted(6),expired(7)

ChurnState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION “The state of the Churn Detection machine.” SYNTAX INTEGER noChurn(1), churn(2), churnMonitor(3)

-- -------------------------------------------------------------

-- --------------------------------------------------------------- groups in the LAG MIB-- -------------------------------------------------------------

dot3adAgg OBJECT IDENTIFIER ::= lagMIBObjects 1 dot3adAggPort OBJECT IDENTIFIER ::= lagMIBObjects 2

-- -------------------------------------------------------------

-- --------------------------------------------------------------- The Tables Last Changed Object-- -------------------------------------------------------------

dot3adTablesLastChanged OBJECT-TYPE SYNTAX TimeTicks



MAX-ACCESS read-only STATUS current DESCRIPTION “This object indicates the time of the most recent change to the dot3adAggTable, dot3adAggPortListTable, or dot3adAggPortTable.”::= lagMIBObjects 3

-- --------------------------------------------------------------- The Aggregator Configuration Table-- -------------------------------------------------------------

dot3adAggTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3adAggEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A table that contains information about every Aggregator that is associated with this System.” REFERENCE “IEEE 802.3 Subclause 30.7.1” ::= dot3adAgg 1

dot3adAggEntry OBJECT-TYPE SYNTAX Dot3adAggEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A list of the Aggregator parameters. This is indexed by the ifIndex of the Aggregator.” INDEX dot3adAggIndex ::= dot3adAggTable 1

Dot3adAggEntry ::= SEQUENCE dot3adAggIndex InterfaceIndex, dot3adAggMACAddress MacAddress, dot3adAggActorSystemPriority INTEGER, dot3adAggActorSystemID MacAddress, dot3adAggAggregateOrIndividual TruthValue, dot3adAggActorAdminKey LacpKey, dot3adAggActorOperKey LacpKey, dot3adAggPartnerSystemID



MacAddress, dot3adAggPartnerSystemPriority INTEGER, dot3adAggPartnerOperKey LacpKey, dot3adAggCollectorMaxDelay INTEGER

dot3adAggIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION “The unique identifier allocated to this Aggregator by the local System. This attribute identifies an Aggregator instance among the subordinate managed objects of the containing object. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.1” ::= dot3adAggEntry 1

dot3adAggMACAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION “A 6-octet read-only value carrying the individual MAC address assigned to the Aggregator.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.9” ::= dot3adAggEntry 2

dot3adAggActorSystemPriority OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION “A 2-octet read-write value indicating the priority value associated with the Actor’s System ID.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.5” ::= dot3adAggEntry 3

dot3adAggActorSystemID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION “A 6-octet read-write MAC address value used as a unique identifier for the System that contains this Aggregator.



NOTE—From the perspective of the Link Aggregation mechanisms described in Clause 43, only a single combination of Actor’s System ID and System Priority are considered, and no distinction is made between the values of these parameters for an Aggregator and the port(s) that are associated with it; i.e., the protocol is described in terms of the operation of aggregation within a single System. However, the managed objects provided for the Aggregator and the port both allow management of these parameters. The result of this is to permit a single piece of equipment to be configured by management to contain more than one System from the point of view of the operation of Link Aggregation. This may be of particular use in the configuration of equipment that has limited aggregation capability (see 43.6).” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.4” ::= dot3adAggEntry 4

dot3adAggAggregateOrIndividual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION “A read-only Boolean value indicating whether the Aggregator represents an Aggregate (‘TRUE’) or an Individual link (‘FALSE’).” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.6” ::= dot3adAggEntry 5

dot3adAggActorAdminKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-write STATUS current DESCRIPTION “The current administrative value of the Key for the Aggregator. The administrative Key value may differ from the operational Key value for the reasons discussed in 43.6.2. This is a 16-bit, read-write value. The meaning of particular Key values is of local significance.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.7” ::= dot3adAggEntry 6

dot3adAggActorOperKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-only STATUS current DESCRIPTION “The current operational value of the Key for the Aggregator. The administrative Key value may differ from the operational Key value for the reasons discussed in 43.6.2. This is a 16-bit read-only value. The meaning of particular Key values is of local significance. REFERENCE “IEEE 802.3 Subclause 30.7.1.1.8”



::= dot3adAggEntry 7

dot3adAggPartnerSystemID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION “A 6-octet read-only MAC address value consisting of the unique identifier for the current protocol Partner of this Aggregator. A value of zero indicates that there is no known Partner. If the aggregation is manually configured, this System ID value will be a value assigned by the local System.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.10” ::= dot3adAggEntry 8

dot3adAggPartnerSystemPriority OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION “A 2-octet read-only value that indicates the priority value associated with the Partner’s System ID. If the aggregation is manually configured, this System Priority value will be a value assigned by the local System.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.11” ::= dot3adAggEntry 9

dot3adAggPartnerOperKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-only STATUS current DESCRIPTION “The current operational value of the Key for the Aggregator’s current protocol Partner. This is a 16-bit read-only value. If the aggregation is manually configured, this Key value will be a value assigned by the local System.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.12” ::= dot3adAggEntry 10

dot3adAggCollectorMaxDelay OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION “The value of this 16-bit read-write attribute defines the maximum delay, in tens of microseconds, that



may be imposed by the Frame Collector between receiving a frame from an Aggregator Parser, and either delivering the frame to its MAC Client or discarding the frame (see 43.2.3.1.1).” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.32” ::= dot3adAggEntry 11

-- --------------------------------------------------------------- The Aggregation Port List Table-- -------------------------------------------------------------

dot3adAggPortListTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3adAggPortListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A table that contains a list of all the ports associated with each Aggregator.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.30” ::= dot3adAgg 2

dot3adAggPortListEntry OBJECT-TYPE SYNTAX Dot3adAggPortListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A list of the ports associated with a given Aggregator. This is indexed by the ifIndex of the Aggregator.” INDEX dot3adAggIndex ::= dot3adAggPortListTable 1

Dot3adAggPortListEntry ::= SEQUENCE dot3adAggPortListPorts PortList

dot3adAggPortListPorts OBJECT-TYPE SYNTAX PortList MAX-ACCESS read-only STATUS current DESCRIPTION “The complete set of ports currently associated with this Aggregator. Each bit set in this list represents an Actor Port member of this Link Aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.30”



::= dot3adAggPortListEntry 1

-- --------------------------------------------------------------- The Aggregation Port Table-- -------------------------------------------------------------

dot3adAggPortTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3adAggPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A table that contains Link Aggregation Control configuration information about every Aggregation Port associated with this device. A row appears in this table for each physical port.” REFERENCE “IEEE 802.3 Subclause 30.7.2” ::= dot3adAggPort 1

dot3adAggPortEntry OBJECT-TYPE SYNTAX Dot3adAggPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A list of Link Aggregation Control configuration parameters for each Aggregation Port on this device.” INDEX dot3adAggPortIndex ::= dot3adAggPortTable 1

Dot3adAggPortEntry ::= SEQUENCE dot3adAggPortIndex InterfaceIndex, dot3adAggPortActorSystemPriority INTEGER, dot3adAggPortActorSystemID MacAddress, dot3adAggPortActorAdminKey LacpKey, dot3adAggPortActorOperKey LacpKey, dot3adAggPortPartnerAdminSystemPriority INTEGER, dot3adAggPortPartnerOperSystemPriority INTEGER, dot3adAggPortPartnerAdminSystemID MacAddress, dot3adAggPortPartnerOperSystemID MacAddress, dot3adAggPortPartnerAdminKey



LacpKey, dot3adAggPortPartnerOperKey LacpKey, dot3adAggPortSelectedAggID InterfaceIndex, dot3adAggPortAttachedAggID InterfaceIndex, dot3adAggPortActorPort INTEGER, dot3adAggPortActorPortPriority INTEGER, dot3adAggPortPartnerAdminPort INTEGER, dot3adAggPortPartnerOperPort INTEGER, dot3adAggPortPartnerAdminPortPriority INTEGER, dot3adAggPortPartnerOperPortPriority INTEGER, dot3adAggPortActorAdminState LacpState, dot3adAggPortActorOperState LacpState, dot3adAggPortPartnerAdminState LacpState, dot3adAggPortPartnerOperState LacpState, dot3adAggPortAggregateOrIndividual TruthValue

dot3adAggPortIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION “The ifIndex of the port” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.1” ::= dot3adAggPortEntry 1

dot3adAggPortActorSystemPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION “A 2-octet read-write value used to define the priority value associated with the Actor’s System ID.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.2” ::= dot3adAggPortEntry 2



dot3adAggPortActorSystemID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION “A 6-octet read-only MAC address value that defines the value of the System ID for the System that contains this Aggregation Port.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.3” ::= dot3adAggPortEntry 3

dot3adAggPortActorAdminKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-write STATUS current DESCRIPTION “The current administrative value of the Key for the Aggregation Port. This is a 16-bit read-write value. The meaning of particular Key values is of local significance.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.4” ::= dot3adAggPortEntry 4

dot3adAggPortActorOperKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-write STATUS current DESCRIPTION “The current operational value of the Key for the Aggregation Port. This is a 16-bit read-only value. The meaning of particular Key values is of local significance.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.5” ::= dot3adAggPortEntry 5

dot3adAggPortPartnerAdminSystemPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION “A 2-octet read-write value used to define the administrative value of priority associated with the Partner’s System ID. The assigned value is used, along with the value of aAggPortPartnerAdminSystemID, aAggPortPartnerAdminKey, aAggPortPartnerAdminPort, and aAggPortPartnerAdminPortPriority, in order to achieve manually configured aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.7” ::= dot3adAggPortEntry 6



dot3adAggPortPartnerOperSystemPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION “A 2-octet read-only value indicating the operational value of priority associated with the Partner’s System ID. The value of this attribute may contain the manually configured value carried in aAggPortPartnerAdminSystemPriority if there is no protocol Partner.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.7” ::= dot3adAggPortEntry 7

dot3adAggPortPartnerAdminSystemID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-write STATUS current DESCRIPTION “A 6-octet read-write MACAddress value representing the administrative value of the Aggregation Port’s protocol Partner’s System ID. The assigned value is used, along with the value of aAggPortPartnerAdminSystemPriority, aAggPortPartnerAdminKey, aAggPortPartnerAdminPort, and aAggPortPartnerAdminPortPriority, in order to achieve manually configured aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.8” ::= dot3adAggPortEntry 8

dot3adAggPortPartnerOperSystemID OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION “A 6-octet read-only MACAddress value representing the current value of the Aggregation Port’s protocol Partner’s System ID. A value of zero indicates that there is no known protocol Partner. The value of this attribute may contain the manually configured value carried in aAggPortPartnerAdminSystemID if there is no protocol Partner.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.9” ::= dot3adAggPortEntry 9

dot3adAggPortPartnerAdminKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-write STATUS current



DESCRIPTION “The current administrative value of the Key for the protocol Partner. This is a 16-bit read-write value. The assigned value is used, along with the value of aAggPortPartnerAdminSystemPriority, aAggPortPartnerAdminSystemID, aAggPortPartnerAdminPort, and aAggPortPartnerAdminPortPriority, in order to achieve manually configured aggregation. REFERENCE “IEEE 802.3 Subclause 30.7.2.1.10” ::= dot3adAggPortEntry 10

dot3adAggPortPartnerOperKey OBJECT-TYPE SYNTAX LacpKey MAX-ACCESS read-only STATUS current DESCRIPTION “The current operational value of the Key for the protocol Partner. The value of this attribute may contain the manually configured value carried in aAggPortPartnerAdminKey if there is no protocol Partner. This is a 16-bit read-only value.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.11” ::= dot3adAggPortEntry 11

dot3adAggPortSelectedAggID OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION “The identifier value of the Aggregator that this Aggregation Port has currently selected. Zero indicates that the Aggregation Port has not selected an Aggregator, either because it is in the process of detaching from an Aggregator or because there is no suitable Aggregator available for it to select. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.12” ::= dot3adAggPortEntry 12

dot3adAggPortAttachedAggID OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION “The identifier value of the Aggregator that this Aggregation Port is currently attached to. Zero indicates that the Aggregation Port is not currently attached to an Aggregator. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.13” ::= dot3adAggPortEntry 13



dot3adAggPortActorPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION “The port number locally assigned to the Aggregation Port. The port number is communicated in LACPDUs as the Actor_Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.14” ::= dot3adAggPortEntry 14

dot3adAggPortActorPortPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION “The priority value assigned to this Aggregation Port. This 16-bit value is read-write.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.15” ::= dot3adAggPortEntry 15

dot3adAggPortPartnerAdminPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION “The current administrative value of the port number for the protocol Partner. This is a 16-bit read-write value. The assigned value is used, along with the value of aAggPortPartnerAdminSystemPriority, aAggPortPartnerAdminSystemID, aAggPortPartnerAdminKey, and aAggPortPartnerAdminPortPriority, in order to achieve manually configured aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.16” ::= dot3adAggPortEntry 16

dot3adAggPortPartnerOperPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION “The operational port number assigned to this Aggregation Port by the Aggregation Port’s protocol Partner. The value of this attribute may contain the manually configured value carried in aAggPortPartnerAdminPort if there is no protocol Partner. This 16-bit value is read-only.”



REFERENCE “IEEE 802.3 Subclause 30.7.2.1.17” ::= dot3adAggPortEntry 17

dot3adAggPortPartnerAdminPortPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION “The current administrative value of the port priority for the protocol Partner. This is a 16-bit read-write value. The assigned value is used, along with the value of aAggPortPartnerAdminSystemPriority, aAggPortPartnerAdminSystemID, aAggPortPartnerAdminKey, and aAggPortPartnerAdminPort, in order to achieve manually configured aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.18” ::= dot3adAggPortEntry 18

dot3adAggPortPartnerOperPortPriority OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION “The priority value assigned to this Aggregation Port by the Partner. The value of this attribute may contain the manually configured value carried in aAggPortPartnerAdminPortPriority if there is no protocol Partner. This 16-bit value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.19” ::= dot3adAggPortEntry 19

dot3adAggPortActorAdminState OBJECT-TYPE SYNTAX LacpState MAX-ACCESS read-write STATUS current DESCRIPTION “A string of 8 bits, corresponding to the administrative values of Actor_State (43.4.2) as transmitted by the Actor in LACPDUs. The first bit corresponds to bit 0 of Actor_State (LACP_Activity), the second bit corresponds to bit 1 (LACP_Timeout), the third bit corresponds to bit 2 (Aggregation), the fourth bit corresponds to bit 3 (Synchronization), the fifth bit corresponds to bit 4 (Collecting), the sixth bit corresponds to bit 5 (Distributing), the seventh bit corresponds to bit 6 (Defaulted), and the eighth bit corresponds to bit 7 (Expired). These values allow administrative control over the values of LACP_Activity, LACP_Timeout and Aggregation. This attribute value is read-write.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.20”



::= dot3adAggPortEntry 20

dot3adAggPortActorOperState OBJECT-TYPE SYNTAX LacpState MAX-ACCESS read-only STATUS current DESCRIPTION “A string of 8 bits, corresponding to the current operational values of Actor_State as transmitted by the Actor in LACPDUs. The bit allocations are as defined in 30.7.2.1.20. This attribute value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.21” ::= dot3adAggPortEntry 21

dot3adAggPortPartnerAdminState OBJECT-TYPE SYNTAX LacpState MAX-ACCESS read-write STATUS current DESCRIPTION “A string of 8 bits, corresponding to the current administrative value of Actor_State for the protocol Partner. The bit allocations are as defined in 30.7.2.1.20. This attribute value is read-write. The assigned value is used in order to achieve manually configured aggregation.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.22” ::= dot3adAggPortEntry 22

dot3adAggPortPartnerOperState OBJECT-TYPE SYNTAX LacpState MAX-ACCESS read-only STATUS current DESCRIPTION “A string of 8 bits, corresponding to the current values of Actor_State in the most recently received LACPDU transmitted by the protocol Partner. The bit allocations are as defined in 30.7.2.1.20. In the absence of an active protocol Partner, this value may reflect the manually configured value aAggPortPartnerAdminState. This attribute value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.2.1.23” ::= dot3adAggPortEntry 23

dot3adAggPortAggregateOrIndividual OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION “A read-only Boolean value indicating whether the



Aggregation Port is able to Aggregate (‘TRUE’) or is only able to operate as an Individual link (‘FALSE’).” REFERENCE “IEEE 802.3 Subclause 30.7.1.1.24” ::= dot3adAggPortEntry 24

-- --------------------------------------------------------------- LACP Statistics Table-- -------------------------------------------------------------

dot3adAggPortStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3adAggPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A table that contains Link Aggregation information about every port that is associated with this device. A row appears in this table for each physical port.” REFERENCE “IEEE 802.3 Subclause 30.7.3” ::= dot3adAggPort 2

dot3adAggPortStatsEntry OBJECT-TYPE SYNTAX Dot3adAggPortStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A list of Link Aggregation Control Protocol statistics for each port on this device.” INDEX dot3adAggPortIndex ::= dot3adAggPortStatsTable 1

Dot3adAggPortStatsEntry ::= SEQUENCE dot3adAggPortStatsLACPDUsRx Counter32, dot3adAggPortStatsMarkerPDUsRx Counter32, dot3adAggPortStatsMarkerResponsePDUsRx Counter32, dot3adAggPortStatsUnknownRx Counter32, dot3adAggPortStatsIllegalRx Counter32, dot3adAggPortStatsLACPDUsTx Counter32, dot3adAggPortStatsMarkerPDUsTx Counter32, dot3adAggPortStatsMarkerResponsePDUsTx Counter32



dot3adAggPortStatsLACPDUsRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of valid LACPDUs received on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.2” ::= dot3adAggPortStatsEntry 1

dot3adAggPortStatsMarkerPDUsRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of valid Marker PDUs received on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.3” ::= dot3adAggPortStatsEntry 2

dot3adAggPortStatsMarkerResponsePDUsRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of valid Marker Response PDUs received on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.4” ::= dot3adAggPortStatsEntry 3

dot3adAggPortStatsUnknownRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of frames received that either: - carry the Slow Protocols Ethernet Type value (43B.4), but contain an unknown PDU, or: - are addressed to the Slow Protocols group MAC Address (43B.3), but do not carry the Slow Protocols Ethernet Type. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.5” ::= dot3adAggPortStatsEntry 4



dot3adAggPortStatsIllegalRx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of frames received that carry the Slow Protocols Ethernet Type value (43B.4), but contain a badly formed PDU or an illegal value of Protocol Subtype (43B.4). This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.6” ::= dot3adAggPortStatsEntry 5

dot3adAggPortStatsLACPDUsTx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of LACPDUs transmitted on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.7” ::= dot3adAggPortStatsEntry 6

dot3adAggPortStatsMarkerPDUsTx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of Marker PDUs transmitted on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.8” ::= dot3adAggPortStatsEntry 7

dot3adAggPortStatsMarkerResponsePDUsTx OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “The number of Marker Response PDUs transmitted on this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.3.1.9” ::= dot3adAggPortStatsEntry 8



-- --------------------------------------------------------------- LACP Debug Table-- -------------------------------------------------------------

dot3adAggPortDebugTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3adAggPortDebugEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A table that contains Link Aggregation debug information about every port that is associated with this device. A row appears in this table for each physical port.” REFERENCE “IEEE 802.3 Subclause 30.7.4” ::= dot3adAggPort 3

dot3adAggPortDebugEntry OBJECT-TYPE SYNTAX Dot3adAggPortDebugEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION “A list of the debug parameters for a port.” INDEX dot3adAggPortIndex ::= dot3adAggPortDebugTable 1

Dot3adAggPortDebugEntry ::= SEQUENCE dot3adAggPortDebugRxState INTEGER, dot3adAggPortDebugLastRxTime TimeTicks, dot3adAggPortDebugMuxState INTEGER, dot3adAggPortDebugMuxReason DisplayString, dot3adAggPortDebugActorChurnState ChurnState, dot3adAggPortDebugPartnerChurnState ChurnState, dot3adAggPortDebugActorChurnCount Counter32, dot3adAggPortDebugPartnerChurnCount Counter32, dot3adAggPortDebugActorSyncTransitionCount Counter32, dot3adAggPortDebugPartnerSyncTransitionCount Counter32, dot3adAggPortDebugActorChangeCount Counter32, dot3adAggPortDebugPartnerChangeCount Counter32



dot3adAggPortDebugRxState OBJECT-TYPE SYNTAX INTEGER current(1), expired(2), defaulted(3), initialize(4), lacpDisabled(5), portDisabled(6) MAX-ACCESS read-only STATUS current DESCRIPTION “This attribute holds the value ‘current’ if the Receive state machine for the Aggregation Port is in the CURRENT state, ‘expired’ if the Receive state machine is in the EXPIRED state, ‘defaulted’ if the Receive state machine is in the DEFAULTED state, ‘initialize’ if the Receive state machine is in the INITIALIZE state, ‘lacpDisabled’ if the Receive state machine is in the LACP_DISABLED state, or ‘portDisabled’ if the Receive state machine is in the PORT_DISABLED state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.2” ::= dot3adAggPortDebugEntry 1

dot3adAggPortDebugLastRxTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION “The value of aTimeSinceSystemReset (F.2.1) when the last LACPDU was received by this Aggregation Port. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.3” ::= dot3adAggPortDebugEntry 2

dot3adAggPortDebugMuxState OBJECT-TYPE SYNTAX INTEGER detached(1), waiting(2), attached(3), collecting(4), distributing(5), collecting_distributing(6) MAX-ACCESS read-only STATUS current DESCRIPTION



“This attribute holds the value ‘detached’ if the Mux state machine (43.4.14) for the Aggregation Port is in the DETACHED state, ‘waiting’ if the Mux state machine is in the WAITING state, ‘attached’ if the Mux state machine for the Aggregation Port is in the ATTACHED state, ‘collecting’ if the Mux state machine for the Aggregation Port is in the COLLECTING state, ‘distributing’ if the Mux state machine for the Aggregation Port is in the DISTRIBUTING state, and ‘collecting_distributing’ if the Mux state machine for the Aggregation Port is in the COLLECTING_DISTRIBUTING state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.4” ::= dot3adAggPortDebugEntry 3

dot3adAggPortDebugMuxReason OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION “A human-readable text string indicating the reason for the most recent change of Mux machine state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.5” ::= dot3adAggPortDebugEntry 4

dot3adAggPortDebugActorChurnState OBJECT-TYPE SYNTAX ChurnState MAX-ACCESS read-only STATUS current DESCRIPTION “The state of the Actor Churn Detection machine (43.4.17) for the Aggregation Port. A value of ‘noChurn’ indicates that the state machine is in either the NO_ACTOR_CHURN or the ACTOR_CHURN_MONITOR state, and ‘churn’ indicates that the state machine is in the ACTOR_CHURN state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.6” ::= dot3adAggPortDebugEntry 5

dot3adAggPortDebugPartnerChurnState OBJECT-TYPE SYNTAX ChurnState MAX-ACCESS read-only STATUS current DESCRIPTION “The state of the Partner Churn Detection machine (43.4.17) for the Aggregation Port. A value of ‘noChurn’ indicates that the state machine is in either the



NO_PARTNER_CHURN or the PARTNER_CHURN_MONITOR state, and ‘churn’ indicates that the state machine is in the PARTNER_CHURN state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.7” ::= dot3adAggPortDebugEntry 6

dot3adAggPortDebugActorChurnCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Actor Churn state machine has entered the ACTOR_CHURN state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.8” ::= dot3adAggPortDebugEntry 7

dot3adAggPortDebugPartnerChurnCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Partner Churn state machine has entered the PARTNER_CHURN state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.9” ::= dot3adAggPortDebugEntry 8

dot3adAggPortDebugActorSyncTransitionCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Actor’s Mux state machine (43.4.15) has entered the IN_SYNC state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.10” ::= dot3adAggPortDebugEntry 9

dot3adAggPortDebugPartnerSyncTransitionCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Partner’s Mux



state machine (43.4.15) has entered the IN_SYNC state. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.11” ::= dot3adAggPortDebugEntry 10

dot3adAggPortDebugActorChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Actor’s perception of the LAG ID for this Aggregation Port has changed. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.12” ::= dot3adAggPortDebugEntry 11

dot3adAggPortDebugPartnerChangeCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION “Count of the number of times the Partner’s perception of the LAG ID (see 43.3.6.1) for this Aggregation Port has changed. This value is read-only.” REFERENCE “IEEE 802.3 Subclause 30.7.4.1.13” ::= dot3adAggPortDebugEntry 12

-- --------------------------------------------------------------- IEEE 802.3ad MIB - Conformance Information-- -------------------------------------------------------------

dot3adAggConformance OBJECT IDENTIFIER ::= lagMIB 2

dot3adAggGroups OBJECT IDENTIFIER ::= dot3adAggConformance 1

dot3adAggCompliances OBJECT IDENTIFIER ::= dot3adAggConformance 2

-- --------------------------------------------------------------- units of conformance-- -------------------------------------------------------------

dot3adAggGroup OBJECT-GROUP OBJECTS dot3adAggActorSystemID, dot3adAggActorSystemPriority, dot3adAggAggregateOrIndividual,



dot3adAggActorAdminKey, dot3adAggMACAddress, dot3adAggActorOperKey, dot3adAggPartnerSystemID, dot3adAggPartnerSystemPriority, dot3adAggPartnerOperKey, dot3adAggCollectorMaxDelay STATUS current DESCRIPTION “A collection of objects providing information about an aggregation.” ::= dot3adAggGroups 1

dot3adAggPortListGroup OBJECT-GROUP OBJECTS dot3adAggPortListPorts STATUS current DESCRIPTION “A collection of objects providing information about every port in an aggregation.” ::= dot3adAggGroups 2

dot3adAggPortGroup OBJECT-GROUP OBJECTS dot3adAggPortActorSystemPriority, dot3adAggPortActorSystemID, dot3adAggPortActorAdminKey, dot3adAggPortActorOperKey, dot3adAggPortPartnerAdminSystemPriority, dot3adAggPortPartnerOperSystemPriority, dot3adAggPortPartnerAdminSystemID, dot3adAggPortPartnerOperSystemID, dot3adAggPortPartnerAdminKey, dot3adAggPortPartnerOperKey, dot3adAggPortSelectedAggID, dot3adAggPortAttachedAggID, dot3adAggPortActorPort, dot3adAggPortActorPortPriority, dot3adAggPortPartnerAdminPort, dot3adAggPortPartnerOperPort, dot3adAggPortPartnerAdminPortPriority, dot3adAggPortPartnerOperPortPriority, dot3adAggPortActorAdminState, dot3adAggPortActorOperState, dot3adAggPortPartnerAdminState, dot3adAggPortPartnerOperState, dot3adAggPortAggregateOrIndividual STATUS current DESCRIPTION



“A collection of objects providing information about every port in an aggregation.” ::= dot3adAggGroups 3

dot3adAggPortStatsGroup OBJECT-GROUP OBJECTS dot3adAggPortStatsLACPDUsRx, dot3adAggPortStatsMarkerPDUsRx, dot3adAggPortStatsMarkerResponsePDUsRx, dot3adAggPortStatsUnknownRx, dot3adAggPortStatsIllegalRx, dot3adAggPortStatsLACPDUsTx, dot3adAggPortStatsMarkerPDUsTx, dot3adAggPortStatsMarkerResponsePDUsTx STATUS current DESCRIPTION “A collection of objects providing information about every port in an aggregation.” ::= dot3adAggGroups 4

dot3adAggPortDebugGroup OBJECT-GROUP OBJECTS dot3adAggPortDebugRxState, dot3adAggPortDebugLastRxTime, dot3adAggPortDebugMuxState, dot3adAggPortDebugMuxReason, dot3adAggPortDebugActorChurnState, dot3adAggPortDebugPartnerChurnState, dot3adAggPortDebugActorChurnCount, dot3adAggPortDebugPartnerChurnCount, dot3adAggPortDebugActorSyncTransitionCount, dot3adAggPortDebugPartnerSyncTransitionCount, dot3adAggPortDebugActorChangeCount, dot3adAggPortDebugPartnerChangeCount STATUS current DESCRIPTION “A collection of objects providing debug information about every aggregated port.” ::= dot3adAggGroups 5

dot3adTablesLastChangedGroup OBJECT-GROUP OBJECTS dot3adTablesLastChanged STATUS current DESCRIPTION “A collection of objects providing information about the time of changes to the configuration of aggregations and their ports.”::= dot3adAggGroup 6



-- -------------------------------------------------------------

-- compliance statements

-- -------------------------------------------------------------

dot3adAggCompliance MODULE-COMPLIANCE

STATUS current

DESCRIPTION

“The compliance statement for device support of

Link Aggregation.”

MODULE

MANDATORY-GROUPS

dot3adAggGroup,

dot3adAggPortGroup,

dot3adTablesLastChangedGroup

GROUP dot3adAggPortListGroup

DESCRIPTION

“This group is optional.”

GROUP dot3adAggPortStatsGroup

DESCRIPTION


GROUP dot3adAggPortDebugGroup

DESCRIPTION


::= dot3adAggCompliances 1

END



Annex 31A

(normative)

MAC Control opcode assignments

Table 31A–1 shows the currently defined opcode values and interpretations:

Opcodes are transmitted high-order octet first. Within each octet, bits are transmitted least-significant bitfirst. Reserved opcodes shall not be used by MAC Control sublayer entities.

Table 31A–2 shows the elements and semantics of the indication_operand_list for MA_CONTROL.indica-tion primitives for each currently defined opcode value in Table 31A–1:

Table 31A–1—MAC Control opcodes

Opcode (Hexadecimal) MAC Controlfunction

Specified inannex Value/comment

00-00 Reserved

00-01 PAUSE 31B Requests that the recipient stop transmitting non-control frames for a period of time indi-cated by the parameters of this function.

00-02 through FF-FF Reserved

Table 31A–2—MAC Control indications

PAUSE (opcode 0x0001)

indication_operand_list element Value Interpretation

pause_status paused Indicates that the PAUSE function is inhibiting transmis-sion of data frames by the MAC client.

not_paused Indicates that the PAUSE function is not inhibiting trans-mission of data frames by the MAC client.



Annex 31B

(normative)

MAC Control PAUSE operation

31B.1 PAUSE description

The PAUSE operation is used to inhibit transmission of data frames for a specified period of time. A MACControl client wishing to inhibit transmission of data frames from another station on the network generates aMA_CONTROL.request primitive specifying:

a) The globally assigned 48-bit multicast address 01-80-C2-00-00-01,

b) The PAUSE opcode,

c) A request_operand indicating the length of time for which it wishes to inhibit data frame transmis-sion. (See 31B.2.)

The PAUSE operation cannot be used to inhibit transmission of MAC Control frames.

PAUSE frames shall only be sent by DTEs configured to the full duplex mode of operation.

The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has been reserved for use in MAC Con-trol PAUSE frames for inhibiting transmission of data frames from a DTE in a full duplex mode IEEE 802.3LAN. IEEE 802.1D-conformant bridges will not forward frames sent to this multicast destination address,regardless of the state of the bridge’s ports, or whether or not the bridge implements the MAC Control sub-layer. To allow generic full duplex flow control, stations implementing the PAUSE operation shall instructthe MAC (e.g., through layer management) to enable reception of frames with destination address equal tothis multicast address.

NOTE—By definition, an IEEE 802.3 LAN operating in full duplex mode comprises exactly two stations, thus there isno ambiguity regarding the destination DTE’s identity. The use of a well-known multicast address relieves the MACControl sublayer and its client from having to know, and maintain knowledge of the individual 48-bit address of theother DTE in a full duplex environment

31B.2 Parameter semantics

The PAUSE opcode takes the following request_operand:

pause_timeA 2-octet, unsigned integer containing the length of time for which the receiving station isrequested to inhibit data frame transmission. The field is transmitted most-significant octet first,and least-significant octet second. The pause_time is measured in units of pause_quanta, equal to512 bit times of the particular implementation (See 4.4). The range of possible pause_time is 0 to65535 pause_quanta.



31B.3 Detailed specification of PAUSE operation

31B.3.1 Transmit operation

Upon receipt of a MA_CONTROL.request primitive containing the PAUSE opcode from a MAC Controlclient, the MAC Control sublayer calls the MAC sublayer TransmitFrame function with the followingparameters:

a) The destinationParam is set equal to the destination_address parameter of the MA_DATA.requestprimitive. This is currently restricted to the value specified in 31B.1.

b) The sourceParam is set equal to the 48-bit individual address of the station.c) The lengthOrTypeParam is set to the reserved 802.3_MAC_Control value specified in 31.4.1.3.d) The dataParam is set equal to the concatenation of the PAUSE opcode encoding (see Annex 31A),

the pause_time request_operand specified in the MA_CONTROL.request primitive (see 2.3.3.2),and a field containing zeroes of the length specified in 31.4.1.6.

Upon receipt of a data transmission request from the MAC Control client through the MA_DATA.requestprimitive, if the transmission of data frames has not been inhibited due to reception of a valid MAC Controlframe specifying the PAUSE operation and a non-zero pause_time, the MAC Control sublayer calls theMAC sublayer TransmitFrame function with the following parameters:

a) The destinationParam is set equal to the destination_address parameter of theMA_CONTROL.request primitive.

b) The sourceParam is set equal to the 48-bit individual address of the station.c) The lengthOrTypeParam and dataParam are set from the m_sdu field of the MA_DATA.request

primitive.

31B.3.2 Transmit state diagram for PAUSE operation

It is not required that an implementation be able to transmit PAUSE frames. MAC Control sublayer entitiesthat transmit PAUSE frames shall implement the Transmit State machine specified in this subclause.

31B.3.2.1 Constantspause_command

The 2-octet encoding of the PAUSE command, as specified in Annex 31A.reserved_multicast_address

The 48-bit address specified in 31B.1 (a).802.3_MAC_Control

The 16 bit type field assignment for 802.3 MAC Control specified in 31.4.1.3.phys_Address

A 48-bit value, equal to the unicast address of the station implementing the MAC Controlsublayer.

31B.3.2.2 VariablestransmitEnabled

A boolean set by Network Management to indicate that the station is permitted to transmiton the network.Values: true; Transmitter is enabled by management

false; Transmitter is disabled by managementtransmission_in_progress

A boolean used to indicate to the Receive State Machine that a TransmitFrame function callis pending.



Values: true; transmission is in progressfalse; transmission is not in progress

n_quanta_txAn integer indicating the number of pause_quanta that the transmitter of a PAUSE frameis requesting that the receiver pause.

pause_timer_DoneA boolean set by the MAC Control PAUSE Operation Receive State Machine to indicatethe expiration of a pause_timer initiated by reception of a MAC Control frame with aPAUSE opcode.Values: true; The pause_timer has expired.

false; The pause_timer has not expired.

31B.3.2.3 FunctionsTransmitFrame

The MAC Sublayer primitive called to transmit a frame with the specified parameters.

31B.3.2.4 Timerspause_timer

The timer governing the inhibition of transmission of data frames from a MAC Client bythe PAUSE function.

31B.3.2.5 MessagesMA_CONTROL.request

The service primitive used by a client to request a MAC Control sublayer function with thespecified request_operands.

MA_DATA.requestThe service primitive used by a client to request MAC data transmission with the specifiedparameters.

31B.3.2.6 Transmit state diagram for PAUSE operation

Figure 31B–1 depicts the Transmit State Diagram for a MAC Control sublayer entity implementing thePAUSE operation.



Figure 31B–1—PAUSE Operation Transmit state diagram

BE

GIN

INIT

IALI

ZE

TX

paus

e_tim

er_D

one

= tr

uetr

ansm

issi

on_i

n_pr

ogre

ss =

fals

e

HA

LT T

X

PA

US

ED

tran

smitE

nabl

ed =

true

tran

smitE

nabl

ed =

true

paus

e_tim

er_D

one

= tr

ue

TR

AN

SM

IT R

EA

DY

MA

_DA

TA

.req

uest

(de

stin

atio

n_ad

dres

s, m

_sdu

, ser

vice

_cla

ss)

*! M

A_C

ON

TR

OL.

requ

est (

rese

rved

_mul

ticas

t_ad

dres

s, p

ause

_com

man

d, n

_qua

nta_

tx)

* pa

use_

timer

_Don

e =

true

SE

ND

CO

NT

RO

L F

RA

ME

tran

smis

sion

_in_

prog

ress

= tr

ueT

rans

mitF

ram

e (r

eser

ved_

mul

ticas

t_ad

dres

s, p

hys_

Add

ress

,

802.

3_M

AC

_Con

trol

, pau

se_c

omm

and

| n_q

uant

a_tx

| ze

roes

)

SE

ND

DA

TA

FR

AM

E

tran

smis

sion

_in_

prog

ress

= tr

ueT

rans

mitF

ram

e (d

estin

atio

n_ad

dres

s, m

_sdu

)

MA

_CO

NT

RO

L.re

ques

t (re

serv

ed_m

ultic

ast_

addr

ess,

pa

use_

com

man

d, n

_qua

nta_

tx)

* pa

use_

timer

_Don

e =

fals

e

paus

e_tim

er_D

one

= fa

lse

MA

_CO

NT

RO

L.re

ques

t (re

serv

ed_m

ultic

ast_

addr

ess,

paus

e_co

mm

and,

n_q

uant

a_tx

) *

paus

e_tim

er_D

one

= tr

ue

tran

smis

sion

_in_

prog

ress

= fa

lse

tran

smis

sion

_in_

prog

ress

= fa

lse

UC

TU

CT

tran

smitE

nabl

ed =

fals

e



31B.3.3 Receive operation

The opcode-independent MAC Control sublayer Receive State Machine accepts and parses valid framesreceived from the MAC sublayer. MAC Control sublayer entities that implement the PAUSE operationshall implement the Receive State machine specified in this subclause. The functions specified in thissubclause are performed upon receipt of a valid Control frame containing the PAUSE opcode, and definethe function called by the INITIATE MAC CONTROL FUNCTION state of Figure 31–4. (See 31.5.3.)

Upon receipt of a valid MAC Control frame with the opcode indicating PAUSE and the destination addressindicating either: (1) the reserved multicast address specified in 31B.1, or (2) the unique physical addressassociated with this station, the MAC Control sublayer starts a timer for the length of time specified by thepause_time request_operand in the Control frame (see 31B.2). The value of the variable pause_timer_Doneis set to false upon the setting of the pause_timer to a non-zero value by the MAC Control PAUSEOperation Receive State Machine. The value of the variable pause_timer_Done is set to true when the timervalue reaches zero (i.e., the timer expires). If the received PAUSE operation indicates a pause_timer valueof zero, the value of pause_timer_Done is set to true immediately.

The receipt of a valid MAC Control frame with the opcode indicating PAUSE and the destination addressindicating the reserved multicast address specified in 31B.1 or the unique physical address associated withthis station will cause the pause_timer to be set according to the pause_time request_operand in the newlyreceived frame, regardless of the current setting of the pause_timer, i.e., new PAUSE operations overrideearlier PAUSE operations.

31B.3.4 Receive state diagram for PAUSE operation

31B.3.4.1 Constants

pause_quantumThe unit of measurement for pause time specified in 31B.2

pause_commandThe 2-octet encoding of the PAUSE command, as specified in Annex 31A.

reserved_multicast_addressThe 48-bit address specified in 31B.1 (a).

phys_AddressA 48-bit value, equal to the unicast address of the station implementing the MAC Controlsublayer.

31B.3.4.2 Variables

n_quanta_rxAn integer used to extract the number of pause quanta to set the pause_timer from thedataParam of the received frame.

opcodeThe opcode parsed from the received frame.

DAThe destination address from the ReceiveFrame function.

transmission_in_progressA boolean used by the Transmit State Machine to indicate that a TransmitFrame functioncall is pending.

Values: true; transmission is in progress

false; transmission is not in progress



31B.3.4.3 Timers

pause_timerThe timer governing the inhibition of transmission of data frames.

31B.3.4.4 Receive state diagram (INITIATE MAC CONTROL FUNCTION) for PAUSE operation

Figure 31B–2 depicts the INITIATE MAC CONTROL FUNCTION for the PAUSE operation. (See 31.5.3.)

31B.3.5 Status indication operation

MAC Control sublayer entities that implement the PAUSE operation shall implement the Indication Statemachine specified in this subclause.

The PAUSE function sets the pause_status variable to one of two values: paused or not_paused, and indi-cates this to its client through the MA_CONTROL.indication primitive.

31B.3.6 Indication state diagram for pause operation

31B.3.6.1 Constantspause_command

The 2-octet encoding of the PAUSE command, as specified in Annex 31A.

31B.3.6.2 Variablespause_status

Used to indicate the state of the MAC Control sublayer for the PAUSE operation. It takesone of two values: paused or not_paused.

pause_timer_DoneA boolean set by the MAC Control PAUSE Operation Receive State Machine to indicatethe expiration of a pause_timer initiated by reception of a MAC Control frame with aPAUSE opcode.

PAUSE FUNCTION

n_quanta_rx = data [17:32]

Start pause_timer (n_quanta_rx * pause_quantum)

opcode = pause_command

WAIT FOR TRANSMISSION COMPLETION

transmission_in_progress = false *

DA = reserved_multicast_address + phys_Address

DA ≠ (reserved_multicast_address + phys_Address)

END PAUSE

UCT

Figure 31B–2—PAUSE Operation Receive state diagram



Values: true; The pause_timer has expired.false; The pause_timer has not expired.

31B.3.6.3 MessagesMA_CONTROL.indication

The service primitive used indicate the state of the MAC Control sublayer to its client.

31B.3.6.4 Indication state diagram for PAUSE operation

Figure 31B–3 depicts the Indication State Diagram for a MAC Control sublayer implementing the PAUSEoperation.

31B.3.7 Timing considerations for PAUSE operation

In a full duplex mode DTE, it is possible to receive PAUSE frames asynchronously with respect to the trans-mission of Data frames. For effective flow control, it is necessary to place an upper bound on the length oftime that a DTE can transmit Data frames after receiving a valid PAUSE frame with a non-zero pause_timerequest_operand.

Reception of a PAUSE frame shall not affect the transmission of a frame that has been submitted by theMAC Control sublayer to the underlying MAC (i.e., the TransmitFrame function is synchronous, and isnever interrupted).

At operating speeds of 100 Mb/s or less, a station that implements an exposed MII, shall not begin to trans-mit a (new) frame (assertion of TX_EN at the MII, see 22.2.2.3) more than pause_quantum bit times afterthe reception of a valid PAUSE frame (de-assertion of RX_DV at the MII, see 22.2.2.6) that contains a non-zero value of pause_time. Stations that do not implement an exposed MII, shall measure this time at theMDI, with the timing specification increased to (pause_quantum + 64) bit times.

At operating speeds above 100 Mb/s, a station shall not begin to transmit a (new) frame more than twopause_quantum bit times after the reception of a valid PAUSE frame that contains a non-zero value ofpause_time, as measured at the MDI.

In addition to DTE and MAC Control delays, system designers should take into account the delay of the linksegment when designing devices that implement the PAUSE operation (see Clause 29).

NOT PAUSED

pause_status = not_paused

MA_CONTROL.indication(pause_command, pause_status)

BEGIN

pause_timer_Done = false

PAUSED

pause_status = paused

MA_CONTROL.indication(pause_command, pause_status)

pause_timer_Done = true

Figure 31B–3—PAUSE Operation Indication state diagram



31B.4 Protocol Conformance Statement (PICS) proforma for MAC Control PAUSE operation69

31B.4.1 Introduction

The supplier of a protocol implementation that is claimed to conform to Annex 31B, MAC Control PAUSEoperation, shall complete the following PICS proforma in addition to the PICS of Clause 31.

A detailed description of the symbols used in the PICS proforma, along with instructions for completing thePICS proforma, can be found in Clause 21.

31B.4.2 Identification

31B.4.2.1 Implementation identification

69Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can beused for its intended purpose and may further publish the completed PICS.

Supplier

Contact point for queries about the PICS

Implementation Name(s) and Version(s)

Other information necessary for full identification—e.g., name(s) and version(s) for machines and/or oper-ating systems; System Names(s)

NOTE 1—Only the first three items are required for all implementations, other information may be completed as appropriate in meeting the requirements for the identification.NOTE 2—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s termi-nology (e.g., Type, Series, Model).



31B.4.2.2 Protocol summary

31B.4.3 Major capabilities/options

31B.4.4 PAUSE command requirements

Identification of protocol specification IEEE Std 802.3, 2000 Edition, Annex 31B, MAC Control PAUSE operation

Identification of amendments and corrigenda to this PICS proforma that have been completed as part of this PICS

Have any Exception items been required? No [ ] Yes [ ](See Clause 21; The answer Yes means that the implementation does not conform to IEEE Std 802.3, 2000 Edition)

Date of Statement

Item Feature Subclause Value/Comment Status Support

*PST

Support for transmit of PAUSE frames

31B.3.2 N/A O Yes [ ]No [ ]

*MIIa

At operating speeds of 100 Mb/s or less, MII connection exists and is accessible for test.

31B.3.7 N/A O Yes [ ]No [ ]

*MIIb

At operating speeds of 100 Mb/s or less, MII connection does not exist or is not accessible for test.

31B.3.7 N/A O Yes [ ]No [ ]

*MIIc

At operating speeds above 100 Mb/s 31B.3.7 N/A O Yes [ ]No [ ]

Item Feature Subclause Value/comment Status Support

PCR1

Duplex mode of DTE 31B.1 Full duplex M Yes [ ]

PCR2

Reception of frames with destination address equal to the multicast address 01-80-C2-00-00-01

31B.1 Enabled M Yes [ ]



31B.4.5 PAUSE command state diagram requirements

31B.4.6 PAUSE command MAC timing considerations

Item Feature Subclause Value/comment Status Support

PSD1

Transmit state diagram for PAUSE operation

31B.3.2 Meets requirements of Figure 31B–1

PST: M

N/A [ ] M:Yes [ ]

PSD2

Receive state diagram for PAUSE operation


M Yes [ ]

PSD3

Indication state diagram for PAUSE operation


M Yes [ ]


TIM1

Effect of PAUSE frame on a frame already submitted to underlying MAC

31B.3.7 Has no effect M Yes [ ]

TIM2

TIM3

TIM4

Delay from receiving valid PAUSE command, with non-zero value for pause_time, to cessation of transmission

Measurement point for sta-tion with MII

Measurement point for sta-tion without MII

Measurement point for sta-tion at greater than 100 Mb/s

31B.3.7 Measured as described

Delay at MDI ≤ pause_quantum bits

Delay at MDI ≤ (pause_quantum + 64) bits

Delay at MDI ≤ (2 × pause-quantum) bits

MIIa: M

MIIb: M

MIIc: M

N/A [ ]M: Yes [ ]

N/A [ ]M: Yes [ ]

N/A [ ]M: Yes [ ]



Annex 32A

(informative)

Use of cabling systems with nominal differential characteristic impedance of 120 Ω or 150 Ω

The 100BASE-T2 standard specifies only the use of 100 Ω link segments for conformance. Since ISO/IEC11801: 1995 also recognizes 120 Ω and 150 Ω cabling, this informative annex specifies the conditions forusing cabling systems with nominal characteristic impedances of 120 Ω and 150 Ω by 100BASE-T2 confor-mant stations.

The use of cabling with a characteristic impedance outside the range specified in 32.7.2.2 will generallyincrease the mismatching effects in the link components if directly coupled to the PHY without a impedancetransforming balun and results in the following consequences:

a) Increased echo due primarily to poorer hybrid performanceb) Increased cabling attenuation roughness due to increased reflectionsc) Increased transmitter launch amplituded) Possible non-linearities in transmitter

The effect of increased echo and reflection is more than compensated by use of Category 4 or higher 120 Ωcabling or 150 Ω cabling consistent with ISO/IEC 11801 specifications. The increased transmitter launchlevel will not be an additional noise or EMC problem on these quality cabling. Manufacturers intending tosupport a direct connection of 120 Ω or 150 Ω cabling to the 100BASE-T2 PHY must ensure that the trans-mitters can tolerate the impedance without additional non-linearity.

If baluns are used instead of a direct connection, care must be taken to ensure that the corner frequencies ofthe baluns do not substantially interfere with the 100BASE-T2 signals. In practice, a lower corner frequencyless than 100 kHz and an upper corner frequency greater than 30 MHz should be adequate for use with Cat-egory 4 or higher 120 Ω cabling or 150 Ω cabling consistent with ISO/IEC 11801 specifications.

CAUTION—Users of the present annex are further advised to check with the manufacturer of the particular 100BASE-T2 devices they intend to use with a 120 Ω or 150 Ω link whether those devices can operate correctly on cabling with Zcas high as 120 Ω ± 15 Ω and 150 Ω ± 15 Ω.



Annex 36A

(informative)

Jitter test patterns

This annex defines test patterns that allow 1000BASE-X PMDs to be tested for compliance while in a sys-tem environment. The patterns may be implemented at a bit, code-group, or frame level and may be used fortransmitter testing. The receiver may not have the capability to accept these diagnostic sequences; however,system debug can be improved if a receiver is able to test for one or more of these patterns and report biterrors (e.g. 8B/10B decoder errors) back to the user.

36A.1 High-frequency test pattern

The intent of this test pattern is to test random jitter (RJ) at a BER of 10–12, and also to test the asymmetry oftransition times. This high-frequency test pattern generates a one, or light on, for a duration of 1 bit time, fol-lowed by a zero, or light off, for a duration of 1 bit time. This pattern repeats continuously for the duration ofthe test. For example: 1010101010101010101010101010101010101010...

NOTE—This pattern can be generated by the repeated transmission of the D21.5 code-group. Disparity rules are fol-lowed.

36A.2 Low-frequency test pattern

The intent of this test pattern is to test low-frequency RJ and also to test PLL tracking error. This low fre-quency test pattern generates a one, or light on, for a duration of 5 bit times, followed by a zero, or light off,for a duration of 5 bit times. This pattern repeats continuously for the duration of the test. For example:1111100000111110000011111000001111100000...

NOTE—This pattern can be generated by the repeated transmission of the K28.7 code-group. Disparity rules are fol-lowed.

36A.3 Mixed frequency test pattern

The intent of this test pattern is to test the combination of RJ and deterministic jitter (DJ). This mixed frequencytest pattern generates a one, or light on, for a duration of 5 bit times, followed by a zero, or light off, for a dura-tion of 1 bit times, followed by a one for 1 bit time followed by a zero for 1 bit time followed by a one for 2 bittimes followed by a zero for 5 bit times followed by a one for 1 bit time followed by a zero for 1 bit time fol-lowed by a one for 1 bit time followed by a zero for 2 bit times. This pattern repeats continuously for the dura-tion of the test. For example: 1111101011000001010011111010110000010100...

NOTE—This pattern can be generated by the repeated transmission of the K28.5 code-group. Disparity rules are fol-lowed.

36A.4 Long continuous random test pattern

The long continuous random test pattern is a random test pattern intended to provide broad spectral contentand minimal peaking that can be used for the measurement of jitter at either a component or system level.



NOTE—The derivation of this pattern may be found in Fibre Channel Jitter Working Group Technical Report [B36].This technical report modified the original RPAT as defined by Fibre Channel so that it would maintain its intended qual-ities but fit into a Fibre Channel frame. This annex uses similar modifications to fit the same RPAT into an 802.3 frame.

The long continuous random test pattern consists of a continuous stream of identical packets, separated by aminimum IPG. Each packet is encapsulated within SPD and EPD delimiters as specified in Clause 36 in theordinary way. The contents of each packet is composed of the following octet sequences, as observed at theGMII, before 8B/10B coding.

Each packet in the long continuous random test pattern consists of 8 octets of PREAMBLE/SFD, followedby 1512 data octets (126 repetitions of the 12-octet modified RPAT sequence), plus 4 CRC octets, followedby a minimum IPG of 12 octets of IDLE.

PREAMBLE/SFD:

55 55 55 55 55 55 55 D5

MODIFIED RPAT SEQUENCE (LOOP 126 TIMES)

BE D7 23 47 6B 8F B3 14 5E FB 35 59

CRC

94 D2 54 AC

IPG (TX_EN and TX_ER low)

00 00 00 00 00 00 00 00 00 00 00 00

END

36A.5 Short continuous random test pattern

The short continuous random test pattern is a random test pattern intended to provide broad spectral contentand minimal peaking that can be used for the measurement of jitter at either a component or system level.

NOTE—The derivation of this pattern may be found in Fibre Channel Jitter Working Group Technical Report [B36].This technical report modified the original RPAT as defined by Fibre Channel so that it would maintain its intended qual-ities but fit into a Fibre Channel frame. This annex uses similar modifications to fit the same RPAT into an 802.3 frame.

The short continuous random test pattern consists of a continuous stream of identical packets, separated by aminimum IPG. Each packet is encapsulated within SPD and EPD delimiters as specified in Clause 36 in theordinary way. The contents of each packet is composed of the following octet sequences, as observed at theGMII, before 8B/10B coding.

Each packet in the short continuous random test pattern consists of 8 octets of PREAMBLE/SFD, followedby 348 data octets (29 repetitions of the 12-octet modified RPAT sequence), plus 4 CRC octets, followed bya minimum IPG of 12 octets of IDLE.

The format of this packet is such that the PCS will generate the following ordered sets for the IPG: /T/ /R/ /I1/ /I2/ /I2/ /I2/ /I2/



PREAMBLE/SFD:

55 55 55 55 55 55 55 D5

MODIFIED RPAT SEQUENCE (LOOP 29 TIMES)

BE D7 23 47 6B 8F B3 14 5E FB 35 59

CRC

2F E0 AA EF

IPG (TX_EN and TX_ER low)

00 00 00 00 00 00 00 00 00 00 00 00

END



Annex 36B

(informative)

8B/10B transmission code running disparity calculation examples

Detection of a invalid code-group in the 8B/10B transmission code does not necessarily indicate that thecode-group in which the error was detected was the one in which the error occurred. Invalid code-groupsmay result from a prior error that altered the running disparity of the bit stream but that did not result in adetectable error at the code-group in which the error occurred. The examples shown in Tables 36B–1 and36B–2 exhibit this behavior. The example shown in Table 36B–3 exhibits the case where a bit error in areceived code-group is detected in that code-group, affects the next code group, and error propagation ishalted upon detection of the running disparity error.

Table 36B–1—RD error detected two code-groups following error

StreamCode-group Code-group Code-group

RD RD RD RD RD RD RD

Transmitted code-group

– D21.1 – D10.2 – D23.5 +

Transmitted bit stream – 101010 - 1001 – 010101 – 0101 – 111010 + 1010 +

Received bit stream – 101010 - 1011a

aBit error introduced (1001 ⇒ 1011)

+ 010101 + 0101 + 111010 +b 1010 +

Received code-group – D21.0 + D10.2 + invalid code-groupb

bNonzero disparity blocks must alternate in polarity (+ ⇒ –). In this case, RD does not alternate (+ ⇒ +),the received code group is not found in the Current RD+ column in either Table 36–1a or Table 36–2, andan invalid code-group is recognized.

+c

cRunning disparity is calculated on the received code-group regardless of the validity of the received code-group. Nonzero disparity blocks prevent the propagation of errors and normalize running disparity to thetransmitted bit stream (i.e., equivalent to the received bit stream had an error not occurred).

Table 36B–2—RD error detected in next code-group following error




– D21.1 – D23.4 – D23.5 +

Transmitted bit stream – 101010 – 1001 – 111010 + 0010 – 111010 + 1010 +

Received bit stream – 101010 – 1011a

aBit error introduced (1001 ⇒ 1011)

+ 111010 +b 0010 – 111010 + 1010 +

Received code-group – D21.0 + invalid code-groupb

bNonzero disparity blocks must alternate in polarity (+ ⇒ –).

– D23.5 +



Table 36B–3—A single bit error affects two received code-groups




– D3.6 (FCS3) – K29.7 (/T/) – K23.7 (/R/) –

Transmitted bit stream – 110001 - 0110 – 101110 + 1000 – 111010 + 1000 –

Received bit stream – 110001 - 0111a +b 101110 +c 1000 – 111010 + 1000 –

Received code-group – invalid code-groupd + invalid code-groupe – K23.7 (/R/) –

aBit error introduced (0110 ⇒ 0111).bNonzero disparity blocks must alternate in polarity (– ⇒ +). Received RD differs from transmitted RD.cNonzero disparity blocks must alternate in polarity (+ ⇒ –). Invalid code-group due to RD error since RD

remains at +.dReceived code-group is not found in either Table 36–1a or Table 36–2.eNonzero disparity blocks prevent the propagation of errors and normalize running disparity to the

transmitted bit stream (i.e. equivalent to the received bit stream had an error not occurred). All code-groupscontained in PCS End_of_Packet delimiters (/T/R/R or /T/R/K28.5/) include nonzero disparity blocks.



Annex 38A

(informative)

Fiber launch conditions

38A.1 Overfilled Launch

Overfilled Launch (OFL), as described in IEC 60793-1-4 [B24], is the standard launch used to define opticalfiber bandwidth. This launch uniformly overfills the fiber both angularly and spatially. It excites both radialand azimuthal modes of the fiber equally, thus providing a reproducible bandwidth which is insensitive tosmall misalignments of the input fiber. It is also relatively insensitive to microbending and macrobendingwhen they are not sufficient to affect power distribution carried by the fiber. A restricted launch gives a lessreproducible bandwidth number and is dependent on an exact definition of the launch. Overfilled launch iscommonly used to measure the bandwidth of LED-based links.

38A.2 Radial Overfilled Launch (ROFL)

A Radial Overfilled Launch is created when a multimode optical fiber is illuminated by the coherent opticaloutput of a source operating in its lowest order transverse mode in a manner that excites predominantly theradial modes of the multimode fiber. This contrasts with the OFL, which is intended to excite both radial andazimuthal modes of the fiber equally. In practice an ROFL is obtained when

a) A spot of laser light is projected onto the core of the multimode fiber,b) The laser spot is approximately symmetrical about the optical center of the multimode fiber,c) The optical axis of both the fiber and the laser beam are approximately aligned,d) The angle of divergence of the laser beam is less than the numerical aperture of the multimode fiber,e) The laser spot is larger than the core of the multimode fiber.

An ROFL cannot be created using a multi-transverse mode laser or by simply projecting a speckle patternthrough an aperture.



Annex 40A

(informative)

Additional cabling design guidelines

This annex provides additional cabling guidelines when installing a new Category 5 balanced cabling systemor using an existing Category 5 balanced cabling system. These guidelines are intended to supplement thosein Clause 40. 1000BASE-T is designed to operate over 4-pair unshielded twisted-pair cabling systems thatmeet both the Category 5 requirements described in ANSI/TIA/EIA-568A (1995) and ISO/IEC 11801:1995,and the additional transmission parameters of return loss, ELFEXT loss, and MDELFEXT loss specified in40.7. There are additional steps that may be taken by network designers that provide additional operatingmargins and ensure the objective BER of 10-10 is achieved. Cabling systems that meet or exceed the specifi-cations in 40.7 for a worst case 4-connector topology are recommended for new installations. Whetherinstalling a new Category 5 balanced cabling system or reusing one that is already installed, it is highlyrecommended that the cabling system be measured/certified before connecting 1000BASE-T equipment fol-lowing the guidelines in (proposed) ANSI/TIA/EIA TSB95.

40A.1 Alien crosstalk

40A.1.1 Multipair cabling (i.e., greater than 4-pair)

Multiple Gigabit Ethernet links [(n*4-Pair) with n greater than 1] should not share a common sheath as in a25-pair binder group in a multipair cable. When the multipair cable is terminated into compliant connectinghardware (TIA does not specify 25 position connecting hardware), the NEXT loss contributions between theadjacent 4-pair gigabit ethernet link, from connecting hardware and the cable combined, cannot be com-pletely cancelled.

40A.1.2 Bundled or hybrid cable configurations

Another source of alien crosstalk can occur in a bundled or hybrid cable configuration where two or more4-pair cables are assembled together.

In order to limit the noise coupled between adjacent 1000BASE-T link segments in a bundled or hybridcable configuration, the PSNEXT loss between a 1000BASE-T duplex channel in a link segment and allduplex channels in adjacent 1000BASE-T link segments should be greater than 35 – 15*log(f/100) (dB) atall frequencies from 1 MHz to 100 MHz.

40A.2 Cabling configurations

The primary application for the Clause 40 specification is expected to be between a workstation and the localtelecommunications closet. In commercial buildings this application is generally referred to as the horizontalcabling subsystem. As specified in ANSI/TIA/EIA-568-A and ISO/IEC 11801: 1995 the maximum length ofa horizontal subsystem building wiring channel is 100 m. The channel consists of cords, cables, and connect-ing hardware. The maximum configuration for this channel is shown in Figure 40A–1.



Figure 40A–1—Maximum horizontal subsystem configuration

On the other hand, a minimum configuration can be achieved by removing the patch cord and transitionpoint, which is shown in Figure 40A–2.

Figure 40A–2—Minimum horizontal subsystem configuration

1000BASE-T is designed to operate over a channel that meets the specifications of 40.7 and the channel con-figuration shown in Figure 40A–1. However, if the channel specifications of 40.8 cannot be met when usingthe channel configuration shown in Figure 40A–1, the configuration shown in Figure 40A–2 is recom-mended. This optimized channel for a 1000BASE-T link segment deletes the transition point and runs anequipment patch cord directly between the LAN equipment and the connector termination of the permanentlink. This reduces the number of connectors and their associated crosstalk in the link. The minimum linkconfiguration:

a) Minimizes crosstalk, both near-end and far-end, which maximizes the BER margin; andb) Minimizes link insertion loss.

Work Area Telecom Closet

Channel

Work Areacable

Equipmentcable

Transition Point Connector

Interconnect Crossconnect

Wall jack

TO

Work Area Telecom Closet

Channel

Work Areacable

Equipmentcable

Interconnect

Wall jack

TO



Annex 40B

(informative)

Description of cable clamp

This annex describes the cable clamp used in the common-mode noise rejection test of 40.6.1.3.3, which isused to determine the sensitivity of the 1000BASE-T receiver to common-mode noise from the linksegment. As shown in Figure 40B–1, the clamp is 300 mm long, 58 mm wide, 54 mm high with a centeropening of 6.35 mm (0.25 in). The clamp consists of two halves that permit the insertion of a cable into theclamp.

Figure 40B–1—Cable clamp

The clamp has a copper center conductor and an aluminum outer conductor with a high density polyethylenedielectric. The following is a review of the construction and materials of the clamp:

a) Inner conductor—Copper tubing with an inner diameter of 6.35 mm (0.25 in) and an outer diameterof 9.4 mm (0.37 in).

b) Outer conductor—Aluminum bar that is 300 mm long and approximately 54 mm by 58 mm. The baris milled to accept the outer diameter of the dielectric material.

c) Dielectric—High Density Polyethylene (Residual, TypeF) with dielectric constant of 2.32. An out-side diameter of 33.5 mm and an inner diameter that accepts the outside diameter of the copper innerconductor.

d) Connectors—BNC connectors are located 9 mm (0.39 in) from each end of the clamp and arerecessed into the outer conductor. The center conductor of the connector is connected to the interconductor as shown in Figure 40B–2.

e) Clamping screws—Six screws are used to connect the two halves of the clamp together after thecable has been inserted. Although clamping screws are shown in Figure 40B–1, any clampingmethod may be used that ensures the two halves are connected electrically and permits quick assem-bly and disassembly.

f) Nylon screws—Used to align and secure the inner conductor and dielectric to the outer conductor.The use and location of the screws is left to the manufacturer.

g) Keying bolts—Two studs used to align the two halves of the clamp.

DIELECTRICOUTER CONDUCTORINNER CONDUCTOR

58 mm

54 mm300 mm

CLAMPINGSCREWSNYLON

SCREWS

KEYINGBOLT

BNC CONNECTOR(9 mm BACK FROM EDGE)

KEYINGBOLT



Figure 40B–2—Cross-section of cable clamp

As shown in Figure 40B–2 the inner conductor on the bottom half of the clamp extends slightly (~ 0.1mm)above the dielectric to ensure there is good electrical connection with the inner conductor of the top half ofthe clamp along the full length of the conductor when the two halves are clamped together.

The electrical parameters of the clamp between 1MHz and 250 MHz are as follows:

a) Insertion loss: < 0.2 dB

b) Return loss: > 20.0 dB

6.35

9.40

THREAD FORCLAMPING SCREW

NYLON SCREW

BNC CONNECTOR

OUTER CONDUCTOR

BRASS SLEEVE

BRASS SCREW

INNER CONDUCTOR

CLAMPINGSCREW HOLE

ALL DIMENSIONS IN MM

DIELECTRIC

27

46

58

33.5

27



40B.1 Cable clamp validation

In order to ensure the cable clamp described above is operating correctly, the following test procedure is pro-vided. Prior to conducting the following test shown in Figure 40B–3, the clamp should be tested to ensurethe insertion loss and return loss are as specified above. The cable clamp validation test procedure uses awell-balanced 4-pair Category 5 unshielded test cable or better that meets the specifications of 40.7. The testhardware consists of the following:

a) Resistor network—Network consists of three 50 ±0.1% Ω resistors; two resistors are connected inseries as a differential termination for cable pairs and the other resistor is connected between the twoand the ground plane as a common-mode termination.

b) Balun—3 ports, laboratory quality with a 100 Ω differential input, 50 Ω differential output, and a 50 Ω common-mode output:

Insertion Loss (100 Ω balanced <->50 Ω unbalanced): <1.2 dB (1-350MHz)

Return Loss: >20 dB (1-350 MHz)

Longitudinal Balance: >50 dB (1-350 MHz)

c) Test cable—4-pair 100 Ω UTP category 5 balanced cable at least 30 m long.

d) Chokes (2)—Wideband Ferrite Material:

Inter-diameter: 6.35 to 6.86 mm

Impedance: 250 Ω @ 100 MHz

e) Ground plane—Copper sheet or equivalent.

f) Signal generator

g) Oscilloscope

h) Receiver

Figure 40B–3—Cable clamp validation test configuration

With the test cable inserted in the cable clamp, a signal generator with a 50 Ω output impedance is connectedto one end of the cable clamp and an oscilloscope with a 50 Ω input impedance is connected to the other end.The signal generator shall be capable of providing a sine wave signal of 1 MHz to 250 MHz. The output ofthe signal generator is adjusted for a voltage of 1.0 Vrms (2.83 Vpp) at 20 MHz on the oscilloscope. Theremainder of the test is conducted without changing the signal generator voltage. The cable pairs not con-nected to the balun are terminated in a resistor network, although when possible it is recommended that eachcable pair be terminated in a balun. It very important that the cable clamp, balun, receiver, and resistor net-works have good contact with the ground plane. The two chokes, which are located next to each other, arelocated approximately 2.0 cm from the clamp. The cable between the clamp and the balun should be straightand not in contact with the ground plane.

Ground Plane

Transmitter/

Cable Clamp

Oscilloscope

Signal Generator1-250 MHz

2 chokes located

from clamp

(see Note 1)

Each cable pairterminated in100 Ohms

Test cable

Balun(s)≅ 20 cm≅ 2 cm

Receiver



The differential-mode and common-mode voltage outputs of the balun should meet the limits shown inTable 40B–1 over the frequency range 1 MHz to 250 MHz for each cable pair. The differential mode voltageat the output of the balun must be increased by 3 dB to take into account the 100-to-50 impedance matchingloss of the balun.

NOTE—Prior to conducting the validation test the cable clamp should be tested without the cable inserted to determinethe variation of the signal generator voltage with frequency at the output of the clamp. The signal generator voltageshould be adjusted to 1 Vrms (2.83 Vpp) at 20 MHz on the oscilloscope. When the frequency is varied from 20 MHz to250 MHz, the voltage on the oscilloscope should not vary more than ±7.5%. If the voltage varies more than ±7.5%, thena correction factor must be applied at each measurement frequency.

Table 40B–1—Common- and differential-mode output voltages

Frequency (f) Common-mode voltage Differential-mode voltage

1-30 MHz <0.1+0.97(f/30) Vpp <2.4 + 19.68 (f/30) mVpp

30-80 MHz <1.07 Vpp <22 mVpp

80-250 MHz <1.07 – 0.6 (f-80)/170 Vpp <22 mVpp



Annex 40C

(informative)

Add-on interface for additional Next Pages

This annex describes a technique for implementing Auto-Negotiation for 1000BASE-T when the implemen-tor wishes to send additional Next Pages (other than those required to configure for 1000BASE-T operation).To accomplish this mode of Auto-Negotiation, the implementor must ensure that the three Next Pagesrequired for 1000BASE-T configuration are sent first.

The add-on interface described in this annex shows one technique for supporting the transmission of addi-tional Next Pages. This mechanism utilizes the existing Clause 28 Auto-Negotiation mechanism and vari-ables defined in Clause 28. Its purpose is merely to provide optional NEXT PAGE WAIT responses to theAuto-Negotiation Arbitration state diagram (see Figure 28–16).

The add-on interface for Auto-Negotiation is intended to interface directly between the defined registers andthe Auto-Negotiation mechanism defined in Clause 28. The mechanism described includes five main blocks(see Figure 40C–1).

The first three blocks are used by the MASTER-SLAVE resolution function. They are used to generate andstore random seeds and to resolve the status of the MASTER-SLAVE relationship. Their operation isdescribed later in this annex. The final two blocks, the transmit state machine for the 1000BASE-T NextPage exchange and the receive state machine for the 1000BASE-T Next Page exchange, are described in thisannex.



Figure 40C–1—Auto-negotiate add-on diagram for 1000BASE-T

NOTE—When the exchange of Next Pages is complete, the MASTER-SLAVE relationship can be determined usingTable 40–5 with the 1000BASE-T Technology Ability Next Page bit values specified in Table 40–4 and informationreceived from the link partner. This process is conducted at the entrance to the FLP LINK GOOD CHECK state shownin the Auto-Negotiation Arbitration State Diagram (Figure 28–16).

REGISTER 10

REGISTER 4

REGISTER 5

REGISTER 6

REGISTER 7

REGISTER 8

REGISTER 9

M/SSEED

LP M/SSEED

M/SRESOLUTION

TXSTATEMACHINE

RXSTATEMACHINE A

UTO

-NE

GO

TIA

TE

link_control(1000T)

link_status

mr_bp[16:1]

mr_np_tx_reg

mr_np_rx

mr_lp_np_able

mr_page_rx

mr_lp_adv_ability

mr_1000t_adv_ability

mr_1000t_lp_adv_ability

config_fault

mr_adv_ability

ack_finished

rx_link_code_word

mr_np_tx

mr_next_page_loaded

mr_page_rx

Registers 1000T Add On

desire_np

mr_np_able

next_page_loaded

mr_np_able

mr_parallel_detect_fault

mr_lp_autoneg_able

mr_lp_np_able

mr_lp_autoneg_able

mr_parallel_detect_fault



40C.1 State variables

mr_bpThis variable is used as an intermediate signal from register 4. Normally register 4 would directlysource the mr_adv_ability information. This information is now sourced from the transmit statemachine.

mr_1000t_adv_abilityA 16-bit array used to store and indicate the contents of register 9.

mr_1000t_lp_adv_abilityA 16-bit array used to write information to register 10.

mr_np_tx_regThis variable is an intermediate signal from register 7. Normally register 7 would directly sourcethe information to the Auto-Negotiation function via mr_np_tx. This information is now sourcedfrom the transmit state machine.

mr_np_rxA 16-bit array used to write information to register 8.Values: Zeros; data bit is logical zero.

One; data bit is logical one.

config_faultThis variable indicates the result of the MASTER-SLAVE resolution function.

next_page_loadedThis variable is an intermediate signal from register 7. Normally register 7 would directly sourcethe information to the Auto-Negotiation function via mr_next_page_loaded. This information is now sourced from the transmit state machine.

reg_randomAn 11-bit array used to store the received random seed from the link partner. It is used by the MASTER-SLAVE resolution function.

1000T_capableThis variable is used merely to show the local device is 1000Base-T capable. It is shown to illustrate the path that a non-1000Base-T device would take within the auto negotiation mechanism.

ATMP_CNTThis variable is used to count the number of failed MASTER-SLAVE resolutions. It has a maximum value of 7.

All other signals are defined in Clause 28.

40C.2 State diagrams

40C.2.1 Auto-Negotiation Transmit state machine add-on for 1000BASE-T

The Auto-Negotiation transmit state machine add-on (see Figure 40C–2) is responsible for sending the BasePage, 1000BASE-T Next Pages, as well as additional Next Pages as specified by the management interface.1000BASE-T Next Pages will automatically be sent by the PHY whenever there are no additional Next



Pages to be sent. If the user desires to send additional Next Pages, then the user must first send three pages ofany format. Management will automatically replace these three pages with the appropriate 1000BASE-TMessage Page and the two following unformatted pages and then will send the additional Next Pages asspecified by the user. All other steps are performed by the management interface. The management interfaceis now required to complete the Next Page exchange by sourcing its own NULL page. This is shown inFigure 40C–2 for illustration only.

Figure 40C–2—Auto-Negotiation Transmit state diagram add-on for 1000BASE-T

Base_Page_TX

1000T_MP_TX

1000T_UP1_TX

1000T_UP2_TX

1000T_NULL_TX

Flp_Link_Good_Check(*3)

Software_NP_TX(*1)

Software_NULL_TX(*2)

mr_np_tx[11:1] ⇐ “8”mr_np_tx[NP] ⇐ 1mr_np_tx[MP] ⇐ 1

mr_np_tx[11:1] ⇐

mr_np_tx[NP] ⇐ 1mr_np_tx[MP] ⇐ 0

mr_np_tx[11:1] ⇐ “reg_random”mr_np_tx[NP] ⇐ mr_bp[NP]mr_np_tx[MP] ⇐ 0

mr_np_tx[11:2] ⇐ “0”(mr_lp_np_able = false *

(1000T_capable = false*mr_bp[NP] = 0)

mr_bp[NP] = 1 *

mr_np_tx_reg[NP] = 1 *

rx_link_code_word[NP] = 1 *

rx_link_code_word[NP] = 0 *

rx_link_code_word[NP] = 1 *rx_link_code_word[NP] = 0 *

Reset_1000T

power_on = true +mr_main_reset = true +mr_restart_negotiation = true +mr_autoneg_enable = false +

ATMP_CNT ⇐ 0

ATMP_CNT ⇐

mr_autoneg_complete = true

mr_np_able ⇐ 1mr_adv_ability[NP] ⇐ 1000T_capable + mr_bp[NP]mr_adv_ability[15:1] ⇐ mr_bp[15:1]

transmit_disable = true

IF(mr_bp[NP] = 1 * mr_lp_np_able = true *next_page_loaded = true) + (mr_bp[NP] = 0 *mr_lp_np_able = true) THEN mr_next_page_loaded ⇐true

IF(mr_bp[NP] = 1 * mr_lp_np_able = true *next_page_loaded = true) + (mr_bp[NP] = 0 *mr_lp_np_able = true) THEN mr_next_page_loaded ⇐true

IF(mr_bp[NP] = 1 * mr_lp_np_able = true*next_page_loaded = true) + (mr_bp[NP] = 0 *mr_lp_np_able = true) THEN mr_next_page_loaded ⇐true

mr_page_rx = true * ack_finished = true

mr_bp[NP] = 0 *

mr_page_rx = true * mr_lp_np_able=true *

mr_page_rx = false


mr_page_rx = false

mr_page_rx = false


mr_page_rx = falsemr_page_rx = true * next_page_loaded= true *

mr_page_rx = true *


mr_page_rx = true *mr_page_rx = true * ack_finished = true


mr_page_rx = true

mr_page_rx = true

mr_page_rx = truenext_page_loaded = true *

next_page_loaded = true *

mr_next_page_loaded ⇐ next_page_loadedmr_np_tx[11:1] ⇐ mr_np_tx_reg[11:1]

WAIT1

WAIT4

WAIT3

WAIT2

mr_np_tx_reg[NP] = 0 * mr_page_rx = true * next_page_loaded = true *

mr_page_rx=true * 1000T_capable=true * ack_finished = true

UCT

mr_page_rx=true) +

ATMP_CNT + 1

mr_lp_np_able=true*

mr_1000t_adv_ability[11:1]

1000T_capable=false * mr_bp[NP]=1

ack_finished = true

ack_finished = true

ack_finished = true

ack_finished = true

mr_np_tx[1] ⇐ “1”mr_np_tx[NP] ⇐ 0mr_no_tx[MP] ⇐ 1mr_next_page_loaded ⇐ next_page_loaded

mr_np_tx[11:2] ⇐ “0”mr_np_tx[1] ⇐ “1”mr_np_tx[NP] ⇐ 0mr_no_tx[MP] ⇐ 1mr_next_page_loaded ⇐ true



NOTES for Figure 40C–2

1—(Software_NP_TX) If the user desires to send additional Next Pages, then the contents of the first three Next Pageswill be overwritten by the three 1000BASE-T Next Pages. In this case, the user is responsible for stepping through theNext Page sequence (by creating the initial three Next Pages to be overwritten by the three 1000BASE-T Next Pages);otherwise the process is automatic. (next_page_loaded signals clear operation as per Clause 28.)

2—(Software_NULL_TX) This is shown for illustration only. This is done in software and is required.

3—(Flp_Link_Good_Check) This is shown for illustration only. This state is from the Auto-Negotiation arbitration statediagram and indicates the conclusion of pages being sent. (The transition 1000T_capable = false is to show sequence fornon 1000BASE-T implementations.)

40C.2.2 Auto-Negotiation receive state diagram add-on for 1000BASE-T

The Auto-Negotiation receive state machine add-on for 1000BASE-T Next Pages (see Figure 40C–3) isresponsible for receiving the Base Page, 1000BASE-T Next Pages, and any additional Next Pages received.1000BASE-T Next Pages will automatically be received whenever the user does not wish to participate inNext Page exchanges. In this case, the appropriate 1000BASE-T message page and its two unformattedpages will automatically be received and stored in their appropriate registers. Any additional Next Pagesreceived will still be placed in register 8, but will be overwritten automatically when a new page is received.The net result is that the management interface does not need to poll registers 6 and 8. The information inregister 8 will be meaningless in this case. If the user desires to participate in additional Next Pageexchanges via setting the appropriate bit in register 4, the user now becomes responsible (as was previouslythe case) for defining how this will be accomplished. In this situation, the first three Next Pages receivedmay be 1000BASE-T and should be discarded. This information will automatically be stored internally inthe appropriate register 10 and reg_random. The management interface/user can ignore the informationreceived for the 1000BASE-T Next Pages.



Figure 40C–3—Auto-Negotiation Receive state diagram add-on for 1000BASE-T

IDLE

Base_Page_RX

1000T_MP_RX

1000T_UP1_RX

1000T_UP2_RX

Software_NP_RX

rx_link_code_word[11,1] = “8” *

rx_link_code_word[11,1] ≠ “8” *

mr_np_rx ⇐ rx_link_code_word




mr_lp_adv_ability ⇐ rx_link_code_word

mr_page_rx = true *base_page

power_on = true +mr_main_reset = true +mr_restart_negotiation = true +mr_autoneg_enable = false +mr_autoneg_complete = true +

mr_1000t_lp_adv_ability ⇐ rx_link_code_word

reg_random ⇐ rx_link_code_word[11:1]

mr_page_rx = false

mr_page_rx = true

transmit_disable = true

mr_page_rx = false

mr_page_rx = true

mr_page_rx = false

mr_page_rx = true

mr_page_rx = false

mr_page_rx = true

mr_page_rx = false

mr_page_rx = true

mr_page_rx = true

WAIT5

WAIT4

WAIT2

WAIT3

WAIT1



Annex 43A

(informative)

Collection and Distribution functions

43A.1 Introduction

The specification of the Collection and Distribution functions was defined with the following considerationsin mind:

a) Frame duplication is not permitted.

b) Frame ordering must be preserved in aggregated links. Strictly, the MAC service specification(ISO/IEC 15802-1) states that order must be preserved for frames with a given SA, DA, and priority;however, this is a tighter constraint than is absolutely necessary. There may be multiple, logicallyindependent conversations in progress between a given SA-DA pair at a given priority; the realrequirement is to maintain ordering within a conversation, though not necessarily betweenconversations.

c) A single algorithm can be defined for the collection function that is independent of the distributionfunction(s) employed by the Partner System.

d) In the interests of simplicity and scalability, the collection function should not perform re-assemblyfunctions, re-order received frames, or modify received frames. Distribution functions, therefore, donot make use of segmentation techniques, do not label or otherwise modify transmitted frames inany way, and must operate in a manner that will inherently ensure proper ordering of receivedframes with the specified collector.

e) The distribution and collection functions need to be capable of handling dynamic changes in aggre-gation membership.

f) There are expected to be many different topologies and many different types of devices in whichLink Aggregation will be employed. It is therefore unlikely that a single distribution function will beapplicable in all cases.

A simple collection function has been specified. The Collector preserves the order of frames received on agiven link, but does not preserve frame ordering amongst links. The distribution function maintains frameordering by

— Transmitting frames of a given conversation on a single link at any time.

— Before changing the link on which frames of a given conversation are transmitted, ensuring that allpreviously transmitted frames of that conversation have been received to a point such that any subse-quently transmitted frames received on a different links will be delivered to the MAC Client at a latertime.

Given the wide variety of potential distribution algorithms, the normative text in Clause 43 specifies only therequirements that such algorithms must meet, and not the details of the algorithms themselves. To clarify theintent, this informative annex gives examples of distribution algorithms, when they might be used, and therole of the Marker protocol (43.5) in their operation. The examples are not intended to be either exhaustiveor prescriptive; implementors may make use of any distribution algorithms as long as the requirements ofClause 43 are met.



43A.2 Port selection

A distribution algorithm selects the port used to transmit a given frame, such that the same port will bechosen for subsequent frames that form part of the same conversation. The algorithm may make use ofinformation carried in the frame in order to make its decision, in combination with other informationassociated with the frame, such as its reception port in the case of a MAC Bridge.

The algorithm may assign one or more conversations to the same port, however, it must not allocate some ofthe frames of a given conversation to one port and the remainder to different ports. The information used toassign conversations to ports could include the following:

a) Source MAC addressb) Destination MAC addressc) The reception portd) The type of destination address (individual or group MAC address)e) Ethernet Length/Type value (i.e., protocol identification)f) Higher layer protocol information (e.g., addressing and protocol identification information from the

LLC sublayer or above)g) Combinations of the above

One simple approach applies a hash function to the selected information to generate a port number. Thisproduces a deterministic (i.e., history independent) port selection across a given number of ports in anaggregation. However, as it is difficult to select a hash function that will generate a uniform distribution ofload across the set of ports for all traffic models, it might be appropriate to weight the port selection in favorof ports that are carrying lower traffic levels. In more sophisticated approaches, load balancing is dynamic;i.e., the port selected for a given set of conversations changes over time, independent of any changes thattake place in the membership of the aggregation.

43A.3 Dynamic reallocation of conversations to different ports

It may be necessary for a given conversation or set of conversations to be moved from one port to one ormore others, as a result of

a) An existing port being removed from the aggregation,b) A new port being added to the aggregation, orc) A decision on the part of the Distributor to re-distribute the traffic across the set of ports.

Before moving conversation(s) to a new port, it is necessary to ensure that all frames already transmitted thatare part of those conversations have been successfully received. The following procedure shows how theMarker protocol (43.5) can be used to ensure that no mis-ordering of frames occurs:

1) Stop transmitting frames for the set of conversations affected. If the MAC Client requests transmis-sion of further frames that are part of this set of conversations, these frames are discarded.

2) Start a timer, choosing the timeout period such that, if the timer expires, the destination System canbe assumed either to have received or discarded all frames transmitted prior to starting the timer.

3) Use the Marker protocol to send a Marker PDU on the port previously used for this set ofconversations.

4) Wait until either the corresponding Marker Response PDU is received or the timer expires. 5) Restart frame transmission for the set of conversations on the newly selected port.

The appropriate timeout value depends on the connected devices. For example, the recommended maximumBridge Transit Delay is 1 second; if the receiving device is a MAC Bridge, it may be expected to have



forwarded or discarded all frames received more than 1 second ago. The appropriate timeout value for othercircumstances could be smaller or larger than this by several orders of magnitude. For example, if the twoSystems concerned are high-performance end stations connected via Gigabit Ethernet links, then timeoutperiods measured in milliseconds might be more appropriate. In order to allow an appropriate timeout valueto be determined, the Frame Collector parameter CollectorMaxDelay (see 43.2.3) defines the maximumdelay that the collector can introduce between receiving a frame from a port and either delivering it to theMAC Client or discarding it. This value will be dependent upon the particular implementation choices thathave been made in a System. As far as the operation of the Collector state machine is concerned, Collector-MaxDelay is a constant; however, a management attribute, aAggCollectorMaxDelay (30.7.1.1.32), is pro-vided that allows interrogation and administative control of its value. Hence, if a System knows the value ofCollectorMaxDelay that is in use by a Partner System, it can set the value of timeout used when flushing alink to be equal to that value of CollectorMaxDelay, plus sufficient additional time to allow for the propaga-tion delay experienced by frames between the two Systems. A value of zero for the CollectorMaxDelayparameter indicates that the delay imposed by the Collector is less than the resolution of the parameter(10 microseconds). In this case, the delay that must be considered is the physical propagation delay of thechannel. Allowing management manipulation of CollectorMaxDelay permits fine-tuning of the value used inthose cases where it may be difficult for the equipment to pre-configure a piece of equipment with a realisticvalue for the physical propagation delay of the channel.

The Marker protocol provides an optimization that can result in faster reallocation of conversations thanwould otherwise be possible—without the use of markers, the full timeout period would always have to beused in order to be sure that no frames remained in transit between the local Distributor and the remote Col-lector. The timeout described recovers from loss of Marker or Marker Response PDUs that can occur.

43A.4 Topology considerations in the choice of distribution algorithm

Figure 43A–1 gives some examples of different aggregated link scenarios. In some cases, it is possible to usedistribution algorithms that use MAC frame information to allocate conversations to links; in others, it isnecessary to make use of higher-layer information.

In example A, there is a many-to-many relationship between end stations communicating over the aggre-gated link. It would be possible for each switch to allocate conversations to links simply on the basis ofsource or destination MAC addresses.

In examples B and C, a number of end stations communicate with a single server via the aggregated link. Inthese cases, the distribution algorithm employed in the server or in Switch 2 can allocate traffic from theserver on the basis of destination MAC address; however, as one end of all conversations constitutes a singleserver with a single MAC address, traffic from the end stations to the server would have to be allocated onthe basis of source MAC address. These examples illustrate the fact that different distribution algorithms canbe used in different devices, as appropriate to the circumstances. The collection function is independent ofthe distribution function(s) that are employed.

In examples D and E, assuming that the servers are using a single MAC address for all of their traffic, theonly appropriate option is for the distribution algorithm used in the servers and switches to make use ofhigher-layer information (e.g., Transport Layer socket identifiers) in order to allocate conversations to links.Alternatively, in example E, if the servers were able to make use of multiple MAC addresses and allocateconversations to them, then the switches could revert to MAC Address-based allocation.



Figure 43A–1—Link aggregation topology examples

Switch 1 Switch 2A

Switch 1 Switch 2B

Switch 1C

D

Switch 1 Switch 2E

Server 1

Server 2

Server 2Server 1

Server 1

Server 1

Individual link

Aggregated links

End station



Annex 43B

(normative)

Requirements for support of Slow Protocols

43B.1 Introduction and rationale

There are two distinct classes of protocols used to control various aspects of the operation of IEEE 802.3devices. They are as follows:

a) Protocols such as the MAC Control PAUSE operation (Annex 31B) that need to process and respondto PDUs rapidly in order to avoid performance degradation. These are likely to be implemented asembedded hardware functions, making it relatively unlikely that existing equipment could be easilyupgraded to support additional such protocols.

NOTE—This consideration was one of the contributing factors in the decision to use a separate group MACaddress to support LACP and the Marker protocol, rather than re-using the group MAC address currently usedfor PAUSE frames.

b) Protocols such as LACP, with less stringent frequency and latency requirements. These may beimplemented in software, with a reasonable expectation that existing equipment be upgradeable tosupport additional such protocols, depending upon the approach taken in the originalimplementation.

In order to place some realistic bounds upon the demands that might be placed upon such a protocolimplementation, this annex defines the characteristics of this class of protocols and identifies some of thebehaviors that an extensible implementation needs to exhibit.

43B.2 Slow Protocol transmission characteristics

Protocols that make use of the addressing and protocol identification mechanisms identified in this annex aresubject to the following constraints:

a) No more than 5 frames shall be transmitted in any one-second period.b) The maximum number of Slow Protocols is 10.

NOTE—This is the maximum number of Slow Protocols that use the specified protocol type defined here. Thatis, there may be more than 10 slow protocols in the universe, but no more than 10 may map to the same EthernetLength/Type field.

c) The MAC Client data generated by any of these protocols shall be in the normal length range for anIEEE 802.3 MAC frame, as specified in 4.4.2. It is recommended that the maximum length for aSlow Protocol frame be limited to 128 octets.

NOTE—The Slow Protocols specified in Clause 43 (i.e., LACP and Marker) conform to this recommendedmaximum.

d) PDUs generated by these protocols shall use the Basic and not the Tagged frame format (seeClause 3).

The effect of these restrictions is to restrict the bandwidth consumed and performance demanded by this setof protocols; the absolute maximum traffic loading that would result is 50 maximum length frames persecond per link.



43B.3 Addressing

The Slow_Protocols_Multicast address has been allocated exclusively for use by Slow Protocols PDUs; itsvalue is identified in Table 43B–1.

NOTES

1—This address is within the range reserved by ISO/IEC 15802-3 (MAC Bridges) for link-constrained protocols. Assuch, frames sent to this address will not be forwarded by conformant MAC Bridges; its use is restricted to a single link.

2—Although the two currently existing Slow Protocols (i.e., LACP and the Marker protocol) always use this MACaddress as the destination address in transmitted PDUs, this may not be true for all Slow Protocols. In some yet-to-be-defined protocol, unicast addressing may be appropriate and necessary. Rather, the requirement is that this address not beused by any protocols that are not Slow Protocols.

43B.4 Protocol identification

All Slow Protocols use Type-field encoding of the Length/Type field, and use the Slow_Protocols_Typevalue as the primary means of protocol identification; its value is shown in Table 43B–2.

The first octet of the MAC Client data following the Length/Type field is a protocol subtype identifier thatdistinguishes between different Slow Protocols. Table 43B-3 identifies the semantics of this subtype.

NOTE—Although this mechanism is defined as part of an IEEE 802.3 standard, it is the intent that the reserved codepoints in this table will be made available to protocols defined by other working groups within IEEE 802, should thismechanism be appropriate for their use.

Table 43B–1—Slow_Protocols_Multicast address

Name Value

Slow_Protocols_Multicast address 01-80-C2-00-00-02

Table 43B–2—Slow_Protocols_Type field

Name Value

Slow_Protocols_Type field 88-09



43B.5 Handling of Slow Protocol frames

Any received MAC frame that carries the Slow_Protocols_Type field value is assumed to be a Slow Protocolframe. An implementation that claims conformance to this standard shall handle all Slow Protocol frames asfollows:

a) Discard any Slow Protocol frame that carries an illegal value of Protocol Subtype (see Table 43B–3).Such frames shall not be passed to the MAC Client.

b) Pass any Slow Protocol frames that carry Protocol Subtype values that identify supported Slow Pro-tocols to the protocol entity for the identified Slow Protocol.

c) Pass any Slow Protocol frames that carry Protocol Subtype values that identify unsupported SlowProtocols to the MAC Client.

NOTE—The intent of these rules is twofold. First, they rigidly enforce the maximum number of Slow Protocols, ensur-ing that early implementations of this mechanism do not become invalidated as a result of “scope creep.” Second, theymake it clear that the appropriate thing to do in any embedded frame parsing mechanism is to pass frames destined forunsupported protocols up to the MAC Client rather than discarding them, thus allowing for the possibility that, in softconfigurable systems, the MAC Client might be enhanced in the future in order to support protocols that were not imple-mented in the hardware.

Table 43B–3—Slow Protocols subtypes

Protocol Subtype value Protocol name

0 Unused—Illegal value

1 Link Aggregation Control Protocol (LACP)

2 Link Aggregation—Marker Protocol

3 Reserved for future use








11–255 Unused—Illegal values



43B.6 Protocol Implementation Conformance Statement (PICS) proforma for Annex 43B, Requirements for support of Slow Protocols70

43B.6.1 Introduction

The supplier of an implementation that is claimed to conform to Annex 43B shall complete the followingProtocol Implementation Conformance Statement (PICS) proforma.

A detailed description of the symbols used in the PICS proforma, along with instructions for completing thePICS proforma, can be found in Clause 21.

70Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can beused for its intended purpose and may further publish the completed PICS.

43B.6.2 Identification

43B.6.2.1 Implementation identification

Supplier (Note 1)

Contact point for queries about the PICS (Note 1)

Implementation Name(s) and Version(s) (Notes 1 and 3)

Other information necessary for full identification—e.g., name(s) and version(s) of machines and/or operating system names (Note 2)

NOTES

1—Required for all implementations.2—May be completed as appropriate in meeting the requirements for the identification.3—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s terminology(e.g., Type, Series, Model).



43B.6.2.2 Protocol summary

43B.6.2.3 Transmission characteristics

43B.6.2.4 Frame handling

Identification of protocol specification IEEE Std 802.3ad-2000, Annex 43B, Requirements for support of Slow Protocols.

Identification of amendments and corrigenda to the PICS proforma which have been completed as part of the PICS

Have any Exception items been required? No [ ] Yes [ ](See Clause 21: the answer Yes means that the implementation does not conform to IEEE Std 802.3ad-2000, Annex 43B, Requirements for support of Slow Protocols.)

Date of Statement


SP1 Transmission rate 43B.2 Max 5 frames in any one-second period

M Yes [ ]

SP2 Frame size 43B.2 Normal IEEE 802.3 frame size range (see 4.4.2)

M Yes [ ]

SP3 Frame format 43B.2 Basic (not Tagged) frame format

M Yes [ ]


FH1 Handling of Slow Protocol frames

43B.5 As specified in 43B.5 M Yes [ ]



Annex 43C

(informative)

LACP standby link selection and dynamic Key management

43C.1 Introduction

While any two ports on a given system that have been assigned the same administrative Key may be capableof aggregation, it is not necessarily the case that an arbitrary selection of such ports can be aggregated. (Keysmay have been deliberately assigned to allow one link to be operated specifically as a hot standby foranother). A system may reasonably limit the number of ports attached to a single Aggregator, or the particu-lar way more than two ports can be combined.

In cases where both communicating systems have constraints on aggregation, it is necessary for them both toagree to some extent on the links to be selected for aggregation and on which not to use. Otherwise it mightbe possible for the two systems to make different selections, possibly resulting in no communication at all.

When one or more links have to be selected as standby, it is possible that they could be used as part of a dif-ferent Link Aggregation Group. For this to happen, one or another of the communicating systems has tochange the operational Key values used for the ports attached to those links.

If the operational Key values were to be changed independently by each system, the resulting set of aggrega-tions could be unpredictable. It is possible that numerous aggregations, each containing a single link, mayresult. Worse, with no constraint on changes, the process of both systems independently searching for thebest combination of operational Key values may never end.

This annex describes protocol rules for standby link selection and dynamic Key management. It providesexamples of a dynamic Key management algorithm applied to connections between systems with variousaggregation constraints.

43C.2 Goals

The protocol rules presented

a) Enable coordinated, predictable, and reproducible standby link selections.

b) Permit predictable and reproducible partitioning of links into aggregations by dynamic Keymanagement.

They do not require

c) A LACP system to understand all the constraints on aggregations of multiple ports that might beimposed by other systems.

d) Correct configuration of parameters, i.e., they retain the plug and play attributes of LACP.



43C.3 Standby link selection

Every link between systems operating LACP is assigned a unique priority. This priority comprises (in prior-ity order) the System Priority, System ID, Port Priority, and Port Number of the higher-priority system. Inpriority comparisons, numerically lower values have higher priority.

Ports are considered for active use in an aggregation in link priority order, starting with the port attached tothe highest priority link. Each port is selected for active use if preceding higher priority selections can alsobe maintained, otherwise the port is selected as standby.

43C.4 Dynamic Key management

Dynamic Key management changes the Key values used for links that either system has selected as astandby to allow use of more links. Whether this is desirable depends on their use. For example, if a singlespanning tree is being used throughout the network, separating standby links into a separate aggregationserves little purpose. In contrast, if equal cost load sharing is being provided by routing, making additionalbandwidth available in a separate Link Aggregation Group may be preferable to holding links in standby toprovide link resilience.

The communicating system with the higher priority (as determined by System Priority and unique SystemID) controls dynamic Key changes. Dynamic Key changes may only be made by this controlling system.

NOTE—The controlling system can observe the port priorities assigned by the Partner system, if it wishes to take theseinto account.

This rule prevents the confusion that could arise if both systems change Keys simultaneously. In principlethe controlling system might search all possible Key combinations for the best way to partition the links intogroups. In practice the number of times that Keys may have to be changed to yield acceptable results issmall.

After each Key change, the controlling system assesses which links are being held in standby by its Partner.Although there is no direct indication of this decision, standby links will be held OUT_OF_SYNC. Aftermatched information is received from the protocol Partner, and before acting on this information, a “settlingtime” allows for the Partner’s aggregate wait delay, and for the selected links to be aggregated. Twice theAggregate Wait Time (the expiry period for the wait_while_timer), i.e., 4 seconds, should be ample. Ifmatched Partner information indicates that all the links that the Actor can make active have been broughtIN_SYNC, it can proceed to change Keys on other links without further delay.

43C.5 A dynamic Key management algorithm

The following algorithm is simple but effective.

After the “settling time” (see 43C.4) has elapsed, the controlling system scans its ports in the Link Aggrega-tion Group (i.e., all those ports with a specific operational Key value that have the same Partner System Pri-ority, System ID, and Key) in descending priority order.

For each port, it may wish to know

a) Is the port (i.e., the Actor) capable of being aggregated with the ports already selected for aggrega-tion with the current Key? Alternatively is the Actor not capable of this aggregation?

b) Is the port’s Partner IN_SYNC or is the Partner OUT_OF_SYNC?



And as it inspects each port it may

c) Select the port to be part of the aggregation with the current Key.d) Retain the current Key for a further iteration of the algorithm, without selecting the port to be part of

the current aggregation.e) Change the operational Key to a new value. Once a new value is chosen, all the ports in the current

Link Aggregation Group that have their Keys changed will be changed to this new value.

As the ports are scanned for the first time

1) The highest priority port is always selected.

If it is capable and IN_SYNC, move to step 2).

Otherwise, change the operational Key of all other ports (if any) in this Link Aggregation Group,and apply this dynamic Key algorithm to those ports, beginning with step 1), after the settling time.

2) Move to the next port.

IF there is a next port, continue at step 3).

Otherwise, dynamic Key changes for ports with this operational Key are complete.

Note that ports that were once in the same aggregation may have had their operational Keys changedto (further) new values. If so, apply the dynamic Key management algorithms to those ports, begin-ning with step 1), after the settling time.

3) If this port is capable and IN_SYNC:

select it, and repeat from step 2).

If this port is OUT_OF_SYNC:

change the operational Key, and repeat from step 2).

If this port is not capable but IN_SYNC:

change the operational Key, move to step 4).

4) Move to the next port.

If there is a next port, continue at step 5).

Otherwise If there are still ports in the current Link Aggregation Group (which will have the currentoperational Key), wait for the settling time and appy the dynamic Key management algorithm,beginning with the first such port, at step 3).

Otherwise, dynamic Key changes for ports with this operational Key are complete.

5) If this port is capable:

retain the current Key and repeat from step 2).

Otherwise, change the operational Key and repeat from step 2).



This procedure is repeated until no OUT_OF_SYNC links remain, or a limit on the number of steps has beenreached.

If the Partner’s System ID changes on any link at any time, the Actor’s operational Key for that link shouldrevert to the administrative Key value, and the dynamic Key procedure should be rerun. This may involvechanging the operational Key values for all the links that were assigned Key values subsequent to the changein Key for the link with the new Partner.

43C.6 Example 1

Two systems, A and B, are connected by four parallel links. Each system can support a maximum of twolinks in an aggregation. They are connected as shown in Figure 43C–1. System A is the higher prioritysystem.

The administrative Key for all of System A and System B’s ports is 1. Neither system knows before the con-figuration is chosen that all its ports would attach to links of the same Partner system. Equally, if the linkswere attached to two different systems, it is not known which pair of links (e.g., 1 and 2, or 1 and 4) wouldbe attached to the same Partner. So choosing the administrative Keys values to be identical for four ports,even though only two could be actively aggregated, is very reasonable.

If there was no rule for selecting standby links, System A and System B might have both selected their ownports 1 and 2 as the active links, and there would be no communication. With the rule, the links A1-B4 andA2-B3 will become active, while A3-B2 and A4-B1 will be standby.

Since System A is the higher-priority system, System B’s operational Key values will remain 1 whileSystem A may dynamically change Keys, though it may choose to retain the standby links. Following theKey management algorithm suggested, System A would be able to change the Keys for A3 and A4 in a littleover 2 seconds (depending on how fast System B completes the process of attaching its ports to the selectedAggregator) after the connections were first made, and both aggregations could be operating within5 seconds.

If System A’s aggregations were to be constrained to a maximum of three links, rather than two, while Sys-tem B’s are still constrained to two, the suggested algorithm would delay for 4 seconds before changingKeys. Both aggregations could be operating within 7 seconds.

Figure 43C–1—Example 1

System A

1

2

3

4

System B

4

3

2

1



43C.7 Example 2

A system has the odd design constraint that each of its four ports may be aggregated with one other asfollows:

a) Port 1 with port 2, or port 4.

b) Port 2 with port 3, or port 1.

c) Port 3 with port 4, or port 2.

d) Port 4 with port 1, or port 3.

This is equivalent to each port being able to aggregate with either neighbor, understanding the ports to bearranged in a circle.

Two such systems are connected with four parallel links as shown in Figure 43C–2.

Just as for Example 1, links A1-B4 and A2-B3 become active without changing the operational Key from itsoriginal administrative value. The Key for A3 and A4 is changed as soon as they become active, and a fewseconds later A3-B2 and A4-B1 become active in a separate aggregation.

If the two systems had been connected as shown in Figure 43C–3:

Figure 43C–2—Example 2a

System A

1

2

3

4

System B

4

3

2

1

Figure 43C–3—Example 2b

System A

4

3

2

1

System B

4

3

2

1



the following would occur, assuming that System A operates the simple algorithm already described.

Initially System A advertises an operational Key equal to the administrative Key value of 1 on all ports. Sys-tem B first selects B1 as active; since the link connects to A1 it has the highest priority. The next highest pri-ority link is B3-A2, but System B cannot aggregate B3 with B1, so System B makes this port standby.System B can aggregate B4-A3, so the port is made active. Finally if B4 is aggregated with B1, B2 cannot beaggregated, so B2 is made standby.

System A, observing the resulting synchronization status from System B, assigns a Key value of 2 to ports 2and 3, retaining the initial Key of 1 for ports 1 and 4. System B will remove B4 from the aggregation withB1, and substitute B2. B3 and B4 will be aggregated. In the final configuration A1-B1 and A4-B2 are aggre-gated, as are A2-B3 and A3-B4.


Additional reference material - pudn.comread.pudn.com/downloads104/doc/428917/802.3-2000_part5.pdf · Additional reference material [B1] ANSI/EIA 364A: ... ANSI/TIA/EIA 526-4A-1997

Documents