[Home] . [What's New?] . [Active Ballots] . [Minutes] . [Meetings] . [Maintenance] . [Interpretations] . [Public Docs] . [Committee Docs]
[Local Address Study Group] . [802 Architecture Group] . [Data Center Bridging Task Group] [Time-Sensitive Networking Task Group]
[Email] . [Ancient Email] . [802.1 MIBs] . [802.1 OIDs] . [IEEE 802] . [IEEE 802 PARs]
TSN: [802] . [802a] . [802b] . [802.1D] . [802.1D-2004] . [802.1G] . [802.1H-REV] . [802.1Q] . [802.1Q-2014] . [802.1s] . [802.1v] . [802.1w] . [802.1AB-2005] . [802.1AB-2009] . [802.1AC-2012] . [802.1AC-2016] . [802.1ad] . [802.1ag] . [802.1ah] . [802.1aj] . [802.1ak] . [802.1ap] . [802.1aq] . [802.1Qaw] . [802.1AX-2008] . [802.1Qay] . [802.1Qbc] . [802.1Qbe] . [802.1Qbf] . [802.1AXbk] . [802.1Qbp] . [802.1AX-2014] . [802.1AX-Rev] . [802.1Qbz] . [802.1Qca]
[802.1AS] . [802.1AS-Rev] . [802.1Qat] . [802.1Qav] . [802.1BA] . [802.1Qbu] . [802.1Qbv] . [802.1CB] . [802.1Qcc] . [802.1Qch] . [802.1CM] . [802.1Qcn] . [802.1Qcp] . [802.1Qcr]
Security: [802.1X-2001] . [802.1X-2004] . [802.1X-2010] . [802.1AE] . [802.1af] . [802.1AR] . [802.1AEbn] . [802.1AEbw] . [802.1Xbx] . [802.1ARce] . [802.1AEcg] . [802.1Xck] . [802E]
DCB: [802.1Qau] . [802.1Qaz] . [802.1Qbb] . [802.1Qbg] . [802.1Qbh] . [802.3bd] . [802.1BR] . [802.1Qcd] . [802.1Qcj] . [802c] . OmniRAN: [802.1CF]

Interpretation #8
IEEE Std. 802.1AB-2005

G.2.2 PMD auto-negotiation advertised capability field The PMD 
auto-negotiation advertised capability field shall contain an 
integer value as defined by the ifMauAutoNegCapAdvertisedBits 
object in IETF RFC 3636

RFC 3636 says:

ifMauAutoNegCapAdvertisedBits OBJECT-TYPE
            SYNTAX      BITS {
                bOther(0),        -- other or unknown
                b10baseT(1),      -- 10BASE-T  half duplex mode
                b10baseTFD(2),    -- 10BASE-T  full duplex mode
                b100baseT4(3),    -- 100BASE-T4
                b100baseTX(4),    -- 100BASE-TX half duplex mode
                b100baseTXFD(5),  -- 100BASE-TX full duplex mode
                b100baseT2(6),    -- 100BASE-T2 half duplex mode
                b100baseT2FD(7),  -- 100BASE-T2 full duplex mode
                bFdxPause(8),     -- PAUSE for full-duplex links
                bFdxAPause(9),    -- Asymmetric PAUSE for full-duplex
                                  --     links
                bFdxSPause(10),   -- Symmetric PAUSE for full-duplex
                                  --     links
                bFdxBPause(11),   -- Asymmetric and Symmetric PAUSE for
                                  --     full-duplex links
                b1000baseX(12),   -- 1000BASE-X, -LX, -SX, -CX half
                                  --     duplex mode
                b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full
                                  --     duplex mode
                b1000baseT(14),   -- 1000BASE-T half duplex mode
                b1000baseTFD(15)  -- 1000BASE-T full duplex mode

RFC 1906 says:

    (3)  When encoding an object whose syntax is described using the BITS
         construct, the value is encoded as an OCTET STRING, in which all
         the named bits in (the definition of) the bitstring, commencing
         with the first bit and proceeding to the last bit, are placed in
         bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
         subsequent octet in turn, followed by as many bits as are needed of
         the final subsequent octet, commencing with bit 8.  Remaining bits,
         if any, of the final octet are set to zero on generation and
         ignored on receipt.

ITU-T Recommendation X.690 says:

    6.2  For the purposes of this Recommendation | International Standard
         only, the bits of an octet are numbered from 8 to 1, where bit 8
         is the "most significant bit", and bit 1 is the "least significant

From this, I conclude that bOther is the MSB of the first octet,
b10baseT is the next octet down, and so on.  That would make a field value of
0x0136 as being:

     b100baseT2FD, bfdxSPause, bfdxBPause, b1000baseXFD, b1000baseT

I.e., at least as I read the standards in question, Wireshark is dissecting
the packet correctly, and if that's not what the folks at Avaya intended,
they misread the standard.

The requester is correct in his assertion that bit 0 of the ifMauAutoNegCapAdvertisedBits
data type would properly be encoded in bit 8 (the most significant bit) of the first
octet of the LLDP PMD auto-negotiation advertised capability field, and that bits 0 through
7 of the bitstring are encoded in bits 8 through 1 of the capability field, respectively,
with bits 8 through 15 of the bitstring being encoded in bits 8 through 1 of the second
octet of the field.

The above describes the bit and octet ordering in the LLDPDU that is passed across the MAC
service boundary between LLDP and the underlying MAC service.  Naturally, the representation
of the data in this field in the MAC data frames, and the subsequent physical encoding,
will follow whatever rules apply to the MAC/PHY technology that supports the operation of
the protocol.

This response was approved by 802.1 at its November 2007 plenary meeting.

Pages copyright © Institute of Electrical and Electronics Engineers, Inc. Please read the rules on Confidentiality Statements and Copyright Notices on Communications. Information on Privacy and opting out of cookies is available. If you have any comments on these pages, please send them to me.

Valid XHTML 1.0 Transitional Valid CSS!

Last modified by jlm, at 2:05pm on Mon, 31 Dec 2007