RE: [802.3ae] FW: WIS MIB list of open issues and recommendations for resolution
Dan,
The POS and other SONET MIB standards were defined before T1.416-1999 was
published. Prior to T1.416-1999 there was not a specific and different
"client" interface for "SONET like" transmission interfaces. Even within
this context T1.416.1999 was referenced only to provide an operational
context for the overhead bytes that were defined and to give a
justification for not defining a SONET interface within the WIS. Also, the
WIS is unique in the use of the existing format for a data originating
interface in a way that has never been recognized until now. It might be
noted that unlike T1.416-1999, the WIS is not a "client" interface, it is a
"peer" service interface.
Thank you,
Roy Bynum
At 09:22 AM 1/2/2002 -0800, C. M. Heard wrote:
>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
>technology.
>
>(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.
>
>Thanks,
>
>Mike