Subject: ifInOctets/ifOutOctets on Ethernet

From: John Flick <[email-masked]>
Date: Wed, 29 Jul 1998 19:55:20 -0700 (PDT)

As we begin work on the gigabit update to RFC 2358, I noticed that I
had a few comments that were sent to me in private e-mail during the
last round after Last Call that we should probably address.  One of
them had to do with the interpretation of ifInOctets/ifOutOctets.

This issue was raised when Dave Perkins pointed out that the
equivalence implied in Section 3.4 between the IEEE octet counters and 
the IF-MIB octet counters was not strictly true, since the IEEE
counters count only the MAC CLIENT DATA and PAD fields in valid
packets.  I agreed that we should add a note in the next round
clarifying that these counters are not strictly equivalent to the
IF-MIB counters, which led to a discussion of what exactly should be
included in the IF-MIB octet counters on Ethernet.  The update to the
IF-MIB that the ifmib WG is working on now specifies that transmission 
MIBs must specify exactly what should be included in these counters.

I believe 2358 suggests that these counters should include all octets
starting from the first octet of the destination address, up to and
including the final octet of the FCS, from valid packets.  The
relevant text is:

  ifInOctets                 The number of octets in valid MAC frames
                             received on this interface, including
                             the MAC header and FCS.

  ifOutOctets                The number of octets transmitted in
                             valid MAC frames on this interface,
                             including the MAC header and FCS.

I am not sure if this is correct. The relevant descriptions of these
objects from RFC 2233 are:

   ifInOctets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of octets received on the interface,
               including framing characters.

               Discontinuities in the value of this counter can occur
               at re-initialization of the management system, and at
               other times as indicated by the value of
               ifCounterDiscontinuityTime."
       ::= { ifEntry 10 }

   ifOutOctets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of octets transmitted out of the
               interface, including framing characters.

               Discontinuities in the value of this counter can occur
               at re-initialization of the management system, and at
               other times as indicated by the value of
               ifCounterDiscontinuityTime."
       ::= { ifEntry 16 }

Note that these descriptions say nothing about whether these include
octets in invalid frames, or what exactly should count as framing
octets.  The questions we should consider, and clearly document
decisions to, are:

  - Should these counts include the PREAMBLE and SFD fields?

  - On half-duplex Gigabit, should these counts include the EXTENSION
    field?

  - Should these counts include octets in invalid frames?  If so, just 
    for the InOctets, or for both?

Opinions, anyone?

John