Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] FW: WIS MIB list of open issues and recommendationsfor resolution

On Mon, 31 Dec 2001, Roy Bynum wrote:
> Because there is becoming a likely hood that the WIS overhead definition
> will be adopted as a separate functional optical link protocol for optical
> switched networks, I would like to see more of a divorce between the WIS
> MIB and SONET.  By making references to the SONET MIB, there is still the
> perception that the WIS is part of SONET.  It is not.  Neither is it part
> of SDH.   I would like to see a totally separate set of definitions for the
> WIS MIB, not references to the SONET MIB or to the SDH MIB.  Personally, I
> think that it should be on a separate AIN branch from SONET or SDH.

Although the WIS is not a subset of SONET or SDH, it does use the same
frame structure as SONET, as is explicitly stated in the following
excerpt from 802.3ae subclause 50.1.1:

  "The WIS maps the encoded Ethernet data received (transmitted) from (to)
   the PCS into a frame structure that has the same format as that defined
   by T1.416-1999, implementing a minimal number of the standard SONET
   overhead fields and functions.  The WIS does not adhere to the electrical
   and optical aspects of SONET specified by T1.416-1999, as it is intended
   to be used with PHYs that conform to the corresponding parameters defined
   by the 10GBASE-W standard."

A consequence of this fact is that the objects in the SONET-MIB's
sonetMediumStuff2, sonetSectionStuff2, sonetLineStuff2,
sonetFarEndLineStuff2, sonetPathStuff2, and sonetFarEndPathStuff2
object groups are valid for the WIS, although only a subset of the
possible values apply for some of the objects.  Furthermore, these
objects are already used in systems where 10 Gb/s Ethernet interfaces
likely to be deployed, and this argues strongly for re-use of these
objects.  Two specific examples of such systems are:

(a) Routers.  It's common now for PoS (PPP over SONET) and ATM over
SONET to be used on a router's WAN interfaces, and the standard means
for managing the SONET sublayers is the SONET-MIB.  Both management
applications and agents exist that know how to deal with it.  Using
the SONET-MIB to manage the WIS would be a way to leverage on that

(b) SONET transport NEs.  It's common for such NEs to have non-SONET
interfaces, i.e., line cards that map non-SONET signals (such as DS3)
into SONET payloads and that perform SONET multiplexing.  A 10GBASE-W
Ethernet interface would technically be a non-SONET interface (since
the optical specs and jitter specs are not SONET-compliant), but thanks
to the use of the WIS there is no format conversion in the payload
mapping.  If such an NE offers an SNMP management interface, then the
SONET-MIB is once again the standard way to manage the SONET interfaces.
Using the SONET-MIB to manage 10GBASE-W tributary interfaces would be
a win in this case, too.

> Because of developments that are taking place in T1X1 and ITU regarding the
> development of a "path relay" type of "Lite LTE" or as it is known to
> 802.3ae an "ELTE" as a standard, it will be better that these two MIBs not
> have references to each other.  The proposed "path relay" may well have two
> separate MIBs, or incorporate only the WIS MIB.  The "path relay" will also
> likely be part of actively managed wavelength transponders, which may be a
> lot less expensive than current LTEs or the proposed Digital Wrapper
> systems.  Over a period of time, this would make the WIS MIB a part of a
> much larger market than it has been previously believed.

The path relay function is in no way unique to ELTE but exists in any
any network element that contains LTE -- in other words, it exists in
any network element that strips off section and line overhead and
extracts the Synchronous Payload Envelope (SPE) at one interface and
inserts that SPE into a different SONET frame (with newly generated
section and line overhead) at another interface.  A typical realization
of ELTE in a SONET ADM would be a 10GBASE-W tributary interface, which
would differ from an OC-192c tributary interface in using different
optics and complying with different jitter specs, but would be essentially
the same in its processing of the section and line overhead.  Thus, the
SONET-MIB's sonetMediumStuff2, sonetSectionStuff2, sonetLineStuff2, and
sonetFarEndLineStuff2 object groups can be used to manage a 10GBASE-W
tributary interface just as well as they can be used to manage an OC-192c
tributary interface.  [Note, however, that the proposed WIS MIB does not
address the management of ELTE, which only contains a subset of the WIS.
This was considered out-of-scope for the present standardization effort.]

> Referencing any of the Existing SONET or SDH MIBs is a mistake.  Even if
> there are objects in the WIS MIB that may have the same function, and
> possibly the same "text", as objects in the SONET or SDH MIBs, they should
> be separate and inclusive within themselves.

To many of us it is anathema to duplicate the definitions of managed
objects in different MIB modules for exactly the same reason that people
frown on cloning text from one standard to another.  802.3ae incorporates
by reference the appropriate definitions from T1.416-1999 rather than
cloning the text.  Similarly, the proposed WIS MIB incorporates by
reference applicable objects from the SONET-MIB.  The same reasons for
doing so apply in both cases.