Subject: Discussion on Redundant Counters for Ethernet over Sonet

From: "Rutt, T E (Tom)" <[email-masked]>
Date: Wed, 11 Apr 2001 15:38:36 -0400

Based on the following message:

> ----------
> From: 	Kaj Tesink[SMTP:[email-masked]]
> Sent: 	Wednesday, April 11, 2001 10:25 AM
> To: 	AToM MIB
> Cc: 	[email-masked]
> Subject: 	Re: cross posting with hubmib
> 
> At 04:13 PM 4/10/01 -0400, Nathan Kohn wrote:
> >atom mib wg:
> >
> >Item of interest from hubmib (ethernet) session
> >[thanks to Steve Moulton for recording this item]
> >"Presentation: WAN Interface Sublayer Management - John Flick.
> >Slides are in IETF50WisMib.ppt.
> >
> >The edge objects defined by SONET do not match up with the EtherNet MIB
> >definitions.  The SONET MIB (AToMMIB) has 15 minute ethernet interval 
> >counters,
> >rather than the traditional SNMP free running counters.  The story was
> told of
> >the old telecom practice of taking pictures of counters on phone switches
> 
> >every
> >fifteen minutes (literal snapshots), and how the current practice echoes
> this
> >historical practice. The SONET MIB has a current table that has the
> current
> >interval,and a 15 minute table.  You can derive the counters from the
> interval
> >tables.  If we do this work, we should do it in cooperation with the
> SONET 
> >guys.
> >
> >The co-chair of the AToM MIB working group, Nathan Kohn agreed, and asked
> for
> >this issue to be cross posted.  Tom Rutt has volunteered to contribute an
> >analysis."
> >
> >kaj et. al, perhaps you could provide some insights into the choice
> between
> >interval vs free-running counters.
> 
> 
> there have been several food fights about this one;
> its one of these differences that we ended up having to
> live with. the 15 minute counts were rooted in telecom
> practices, methods&procedures and implementations.
> when snmp showed up with continues counters as the
> common practice (and simple to implement)
> the trunk-mib wg ran into this question
> for the ds1 mib. common implementations as well as
> leading specifications pretty much decided what the answer
> should be for the ds1 mib. subsequently the ds3, sonet and ds0 mibs
> then simply built on the model set by the ds1 mib.
> inside bellcore we did take a look at the extent to which
> 15-minute bucket counts would be translatable into continuous
> counts or vice versa. the answer was: to some extent it is just
> representation but there are subtle differences that you have to
> live with, i.e., under some circumstances true translation
> may not be possible. also, differences were identified in
> the smarts of the agent where the 15 min buckets need to be stored
> for a while (and you need to worry about border conditions),
> and where the continuous counts rely more or
> periodic retrieval of the count value. you can come up
> with pros and cons for each method.
> 
> overall my own inclination is
> a) to avoid mibs that do it both ways ("options") for
>     the same counter flavors
> b) to pick the method that is compatible with what is
>     common practice in both current equipment and
>     current methods&procedures by those who must use it
> c) in a desert environment (is there such a thing?)
>     the continuous counter method
>     tends to be simpler for agent implementation
> 
> it may not be optimal but we do want specifications
> that will also be implemented, no?
> 
> kaj
> 
> 
> 
> 
> 
> >nathan kohn
> 
> 
> 
	I post the following discussion item:

	Tom Rutt
	[email-masked]

	---------------------------

This mail message provides a short summary of the issue regarding 
Potentially redundant interface counters in the Wan Interface Sublayer
case of a 1 to 1 mapping of 10GB ethernet MAC layer onto SONET.

Further discussion is required to resolve the MIB design issues for 10 Gbit
ethernet.

1.	Interface Counters for 10GB WAN Interface Sublayer MIB Design

802.1ae section 50 defines a Wan Interface Sublayer (WIS), as follows
"
The WAN Interface Sublayer (WIS) is an optional PHY sublayer that may be 
used to create a 10GBASE-W PHY that is data-rate and format compatible 
with the SONET STS-192c transmission format defined by ANSI, as well as 
the Synchronous Digital Hierarchy (SDH) VC-4-64c container sp
ecified by ITU. The pur-pose of the WIS is to allow 10GBASE-W 
equipment to generate Ethernet data streams that may be mapped
directly to STS-192c or VC-4-64c streams at the PHY level, without requiring
MAC or higher-layer process-ing. The WIS therefore specifies a subset of the
logical frame formats in the SONET and SDH standards. In
addition, the WIS constrains the effective data throughput at its service
interface to the payload capacity of STS-192c / VC-4-64c, i.e., 9.58464
Gb/s. Multiplexed SONET/SDH formats are not supported.
"

Thus the WIS can be viewed as a 1 to 1 mapping of the Ethernet MAC layer
interface onto a single sonet interface.  This 1 to 1 mapping brings up
questions regarding usefulness of potentially redundant counters.

The MIB definitions to handle the WIS case bring up the question of which
set of counters to use, the Ethernet continuous counters or the sonet
interval counters.

From the nature of the counter definitions, as summarized in sections 2 
and 3 below, it is not practical to derive the Ethernet like counter values
from the Sonet counters.

At first look there seems to be two possibilities for the WIS MIB:

a) The WIS agent implementation will decide whether to expose the highest
layer counters as Sonet counters or as Ethernet counters.

b) The WIS agent will expose the Ethernet counters as well as the full set
of Sonet layer Counters.

Further discussion is required on these, or other, possibilities.

In particular, if b) is chosen, it must be decided which Sonet layers for 
counting must be implemented for a WIS Agent which implements the Ethernet
like interface continuous counters. 

2.	Counters used in Ethernet Interface MIB (RFC 2665)

2.1	Generic Counters for interfaces (RFC 2233)

RFC 2233 defines two tables for counters associated with interface types:

		ifTable OBJECT-TYPE
		       SYNTAX      SEQUENCE OF IfEntry
		       MAX-ACCESS  not-accessible
		       STATUS      current
		       DESCRIPTION
		              "A list of interface entries.  The number of
entries
		               is given by the value of ifNumber."
		       ::= { interfaces 2 }

		ifEntry OBJECT-TYPE
		       SYNTAX      IfEntry
		       MAX-ACCESS  not-accessible
		       STATUS      current
		       DESCRIPTION
		            "An entry containing management information
applicable
		               to a particular interface."
		       INDEX   { ifIndex }
		       ::= { ifTable 1 }

		IfEntry ::=
		       SEQUENCE {
		           ifIndex                 InterfaceIndex,
		           ifDescr                 DisplayString,
		           ifType                  IANAifType,
		           ifMtu                   Integer32,
		           ifSpeed                 Gauge32,
		           ifPhysAddress           PhysAddress,
		           ifAdminStatus           INTEGER,
		           ifOperStatus            INTEGER,
		           ifLastChange            TimeTicks,
		           ifInOctets              Counter32,
		           ifInUcastPkts           Counter32,
		           ifInNUcastPkts          Counter32,  -- deprecated
		           ifInDiscards            Counter32,
		           ifInErrors              Counter32,
		           ifInUnknownProtos       Counter32,
		           ifOutOctets             Counter32,
		           ifOutUcastPkts          Counter32,
		           ifOutNUcastPkts         Counter32,  -- deprecated
		           ifOutDiscards           Counter32,
		           ifOutErrors             Counter32,
		           ifOutQLen               Gauge32,    -- deprecated
		           ifSpecific              OBJECT IDENTIFIER --
deprecated
		       }
and
		ifXTable        OBJECT-TYPE
		       SYNTAX      SEQUENCE OF IfXEntry
		       MAX-ACCESS  not-accessible
		       STATUS      current
		       DESCRIPTION
		              "A list of interface entries.  The number of
entries
		               is given by the value of ifNumber.  This
table
		             contains additional objects for the interface
table."
		       ::= { ifMIBObjects 1 }

		ifXEntry        OBJECT-TYPE
		       SYNTAX      IfXEntry
		       MAX-ACCESS  not-accessible
		       STATUS      current
		       DESCRIPTION
		            "An entry containing additional management
information
		               applicable to a particular interface."
		       AUGMENTS    { ifEntry }
		       ::= { ifXTable 1 }

		IfXEntry ::=
		       SEQUENCE {
		           ifName                  DisplayString,
		           ifInMulticastPkts       Counter32,
		           ifInBroadcastPkts       Counter32,
		           ifOutMulticastPkts      Counter32,
		           ifOutBroadcastPkts      Counter32,
		           ifHCInOctets            Counter64,
		           ifHCInUcastPkts         Counter64,
		           ifHCInMulticastPkts     Counter64,
		           ifHCInBroadcastPkts     Counter64,
		           ifHCOutOctets           Counter64,
		           ifHCOutUcastPkts        Counter64,
		           ifHCOutMulticastPkts    Counter64,
		           ifHCOutBroadcastPkts    Counter64,
		           ifLinkUpDownTrapEnable  INTEGER,
		           ifHighSpeed             Gauge32,
		           ifPromiscuousMode       TruthValue,
		           ifConnectorPresent      TruthValue,
		           ifAlias                 DisplayString,
		           ifCounterDiscontinuityTime TimeStamp
		       }

2.2	RFC 2665 Ethernet Interface Counters

RFC 2233 Counters, as used by the Ethernet Interfaces RFC 2665 MIB are:
		ifInOctets                 The number of octets in valid MAC
		                            frames received on this
interface,
		                            including the MAC header and
FCS.
		                            This does include the number of
octets
		                           in valid MAC Control frames
received on
		                           this interface.

		ifInUcastPkts              Refer to [25].  Note that this
does
		                            not include MAC Control frames,
since
		                            MAC Control frames are consumed
by the
		                            interface layer and are not
passed to
		                            any higher layer protocol.

		ifInDiscards               Refer to [25].

		ifInErrors                 The sum for this interface of
		                            dot3StatsAlignmentErrors,
		                            dot3StatsFCSErrors,
		                            dot3StatsFrameTooLongs,
	
dot3StatsInternalMacReceiveErrors, and
		                            dot3StatsSymbolErrors.

		ifInUnknownProtos          Refer to [25].

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

		ifOutUcastPkts             Refer to [25].  Note that this
does
		                           not include MAC Control frames,
since
		                           MAC Control frames are generated
by the
		                           interface layer, and are not
passed
		                           from any higher layer protocol.

		fOutDiscards              Refer to [25].

		ifOutErrors                The sum for this interface of:
		                          dot3StatsSQETestErrors,
		                          dot3StatsLateCollisions,
		                          dot3StatsExcessiveCollisions,
		                          dot3StatsInternalMacTransmitErrors
and
		                          dot3StatsCarrierSenseErrors.

		ifInMulticastPkts          Refer to [25].  Note that this
does
		                           not include MAC Control frames,
since
		                           MAC Control frames are consumed
by the
		                          interface layer and are not passed
to
		                          any higher layer protocol.

		ifInBroadcastPkts          Refer to [25].  Note that this
does
		                           not include MAC Control frames,
since
		                           MAC Control frames are generated
by
		                           the interface layer, and are not
passed
		                           from any higher layer protocol.

		ifOutMulticastPkts         Refer to [25].  Note that this
does
		                           not include MAC Control frames,
since
		                           MAC Control frames are consumed
by the
		                           interface layer and are not
passed to
		                           any higher layer protocol.

		ifOutBroadcastPkts         Refer to [25].  Note that this
does
		                           not include MAC Control frames,
since
		                           MAC Control frames are generated
by
		                           the interface layer, and are not
passed
		                           from any higher layer protocol.

		ifHCInOctets            64-bit versions of counters.
Required
		ifHCOutOctets         for ethernet-like interfaces that are
		                             capable of operating at
20Mbit/sec or
		                                 faster, even if the
interface is
		                                 currently operating at less
than
		                                 20Mbit/sec.

		 ifHCInUcastPkts            64-bit versions of packet
counters.
		 ifHCInMulticastPkts        Required for ethernet-like
interfaces
		 ifHCInBroadcastPkts        that are capable of operating at
		 ifHCOutUcastPkts           640Mbit/sec or faster, even if
the
		 ifHCOutMulticastPkts       interface is currently operating
at
		 ifHCOutBroadcastPkts       less than 640Mbit/sec.

In addition the following table entry is defined for additional Dot3
Statistics:

		dot3StatsTable OBJECT-TYPE
		           SYNTAX     SEQUENCE OF Dot3StatsEntry
		           MAX-ACCESS not-accessible
		           STATUS     current
		         DESCRIPTION "Statistics for a collection of
ethernet-like
		                       interfaces attached to a particular
system.
		                     There will be one row in this table for
each
		                       ethernet-like interface in the
system."
		           ::= { dot3 2 }

		       dot3StatsEntry OBJECT-TYPE
		           SYNTAX     Dot3StatsEntry
		           MAX-ACCESS not-accessible
		           STATUS     current
		          DESCRIPTION "Statistics for a particular interface
to an
		                       ethernet-like medium."
		           INDEX       { dot3StatsIndex }
		           ::= { dot3StatsTable 1 }

		Dot3StatsEntry ::=
		           SEQUENCE {
		               dot3StatsIndex
InterfaceIndex,  
		                   //same value as ifIndex
		               dot3StatsAlignmentErrors
Counter32,
		               dot3StatsFCSErrors
Counter32,
		               dot3StatsSingleCollisionFrames
Counter32,
		               dot3StatsMultipleCollisionFrames
Counter32,
		               dot3StatsSQETestErrors
Counter32,
		               dot3StatsDeferredTransmissions
Counter32,
		               dot3StatsLateCollisions
Counter32,
		               dot3StatsExcessiveCollisions
Counter32,
		               dot3StatsInternalMacTransmitErrors
Counter32,
		               dot3StatsCarrierSenseErrors
Counter32,
		               dot3StatsFrameTooLongs
Counter32,
		               dot3StatsInternalMacReceiveErrors
Counter32,
		               dot3StatsEtherChipSet               OBJECT
IDENTIFIER,
		               dot3StatsSymbolErrors
Counter32,
		               dot3StatsDuplexStatus               INTEGER
		           }

In the 10 Gbit Ethernet, some of the counters are not relevant (e.g., there
are no collisions).

3.	Sonet MIB Counters

The Sonet MIB (RFC 2558) only requires the ifGeneralInformationGroup from
RFC 2233.  Counters from the RFC 2233 are not used in the Sonet MIB.

The Sonet MIB supports the following layered structure:

                 _____________________________
                |             |          |    |  >
                |             |          |    |  |
                |    VT 1     |..........|VT K|   > K ifEntries
                |             |          |    |  |
                |_____________|__________|____|  >
                |               |      |      |  >
                |               |      |      |  |
                |    Path 1     |......|Path L|   > L ifEntries
                |               |      |      |  |
                |_______________|______|______|  >
                |                             |  >
                |                             |  |
                |    Line                     |  |
                |                             |  |
                |_____________________________|  |
                |                             |  |
                |                             |  |
                |    Section Layer            |   > 1 ifEntry
                |                             |  |
                |_____________________________|  |
                |                             |  |
                |                             |  |
                |    Physical Medium Layer    |  |
                |                             |  |
                |_____________________________|  >

                Use of ifTable for a SONET/SDH port

Sonet counters are derived from hidden frame error counters, and reported
using regular time intervals (e.g., 15 minute).  RFC 2558 defines two tables
per layer, one for holding the current values as well as values for prior
historical Intervals.

The following three tables are specific to a given layer:
  SonetSectionCurrentEntry ::=
    SEQUENCE {
        sonetSectionCurrentStatus   Integer32,
        sonetSectionCurrentESs      PerfCurrentCount,
        sonetSectionCurrentSESs     PerfCurrentCount,
        sonetSectionCurrentSEFSs    PerfCurrentCount,
        sonetSectionCurrentCVs      PerfCurrentCount
    }

  SonetSectionIntervalEntry ::=
    SEQUENCE {
         sonetSectionIntervalNumber  Integer32,
         sonetSectionIntervalESs     PerfIntervalCount,
         sonetSectionIntervalSESs    PerfIntervalCount,
         sonetSectionIntervalSEFSs   PerfIntervalCount,
         sonetSectionIntervalCVs     PerfIntervalCount,
         sonetSectionIntervalValidData  TruthValue
    }

  SonetLineCurrentEntry ::=
    SEQUENCE {
         sonetLineCurrentStatus    Integer32,
         sonetLineCurrentESs       PerfCurrentCount,
         sonetLineCurrentSESs      PerfCurrentCount,
         sonetLineCurrentCVs       PerfCurrentCount,
         sonetLineCurrentUASs      PerfCurrentCount
     }

The following tables exist for layers xxx = SonetPath and SonetVT:

  xxxCurrentEntry ::=
    SEQUENCE {
        xxxCurrentWidth      INTEGER,
        xxxCurrentStatus     Integer32,
        xxxCurrentESs        PerfCurrentCount,
        xxxCurrentSESs       PerfCurrentCount,
        xxxCurrentCVs        PerfCurrentCount,
        xxxCurrentUASs       PerfCurrentCount
     }

The following tables exist for layers yyy = SonetFarEndLine,
SonetFarEndPath, and SonetFarEndVT:

  yyyCurrentEntry ::=
    SEQUENCE {
        yyyCurrentESs       PerfCurrentCount,
        yyyCurrentSESs      PerfCurrentCount,
        yyyCurrentCVs       PerfCurrentCount,
        yyyCurrentUASs      PerfCurrentCount
    }

The following tables exist for layers zzz = SonetPath, SonetVT
SonetFarEndLine, SonetFarEndPath, SonetFarEndVT, and SonetLine:
  
 zzzIntervalEntry ::=
    SEQUENCE {
        zzzIntervalNumber    Integer32,
        zzzIntervalESs       PerfIntervalCount,
        zzzIntervalSESs      PerfIntervalCount,
        zzzIntervalCVs       PerfIntervalCount,
        zzzIntervalUASs      PerfIntervalCount,
        zzzIntervalValidData TruthValue
    }

The relevant definitions for these counter objects is:
		Coding Violation
		   Coding Violations (CV) are Bit Interleaved Parity (BIP)
errors
		   that are detected in the incoming signal.  CV counters
are
		   incremented for each BIP error detected.  That is, each
BIP-8
		   can detect up to eight errors per STS-N frame, with each
error
		   incrementing the CV counter.  Section CVs shall be
collected
		   using the BIP-8 in the B1 byte located in the Section
Overhead
		   of STS-1 #1. Line CVs shall be collected using the BIP-8s
in B2
		   bytes located in the Line Overhead of each STS-1 (since
all CVs
		   on an STS-N line are counted together, this is equivalent
to
		   counting each error in the BIP-8*N contained in the B2
bytes of
		   the STS-N Line Overhead). Thus, on an STS-N signal, up to
8 x N
		   CVs may occur in each frame.  Path CVs shall be collected
using
		   the BIP-8 in the B3 byte of the STS-Path Overhead of the
STS
		   SPE.  VT CVs shall be collected using the BIP-2 in the V5
		   overhead byte of the floating VT.

		Errored Seconds
		   At each layer, an Errored Second (ES) is a second with
one or
		   more Coding Violations at that layer OR one or more
incoming
		   defects (e.g., SEF, LOS, AIS, LOP) at that layer has
occurred.

		Severely Errored Seconds
		   According to [22][31][32][34][35] at each layer, an
Severely
		   Errored Second (SES) is a second with x or more CVs at
that
		   layer, or a second during which at least one or more
incoming
		   defects at that layer has occurred.  The values of x in
		   RFC1595[30] were based on [22] and [32] (see Appendix B).
These
		   values have subsequently been relaxed in [31][34][35]. In
		   addition, according to G.826 [33] SESs are measured as a
		   percentage of errored blocks.

		   To deal with these sets of definitions this memo defines
an
		   object sonetSESThresholdSet that determines the correct
		   interpretation of SES. For backward compatibility, if
this
		   object is not implemented the interpretation of Appendx B
shall
		   apply.  Otherwise, a more recent interpretation is
suggested.
		   An agent is not required to support all sets of
definitions.

		   Note that if a manager changes the value of this object
all SES
		   statistics collected prior to this change shall be
invalidated.

		Severely Errored Framing Seconds
		   A Severely Errored Framing Second (SEFS) is a second
containing
		   one or more SEF events.  This counter is only counted at
the
		   Section Layer.

		Unavailable Seconds
		   At the Line, Path, and VT layers, an unavailable second
is
		   calculated by counting the number of seconds that the
interface
		   is unavailable.  At each layer, the SONET/SDH interface
is said
		   to be unavailable at the onset of 10 contiguous SESs.
The 10
		   SESs are included in unavailable time.  Once unavailable,
the
		   SONET/SDH interface becomes available at the onset of 10
		   contiguous seconds with no SESs.  The 10 seconds with no
SESs
		   are excluded from unavailable time.  With respect to the
		   SONET error counts at each layer, all counters at that
layer
		   are incremented while the SONET/SDH interface is deemed
		   available at that layer.  While the interface is deemed
		   unavailable at that layer, the only count that is
incremented
		   is UASs at that layer.