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

AW: [802.3ae_Serial] another question on pattertn defined in the current draft:




Hi,
I thought that there are reasons. However I assume that this for my
understanding a functioning an ASIC normally, so we are driving an ASIC test
with a network level procedure. This in fact has some ugly effects on a
possible transport layer some of them are covered in my second mail I
responded to Piers statement (there might be more but this is not my focus
area).  This will in any case make life a lot more complicated for transport
network operators. Again the effects I see on the short hand are:
 
Sonet receiver will generate LOF but no real LOS as power is there. This
will be interpreted as invalid input signal so may be mis connection. There
is not any standardized interpretation for this as the Primary alarm will be
displayed. So the interpretation of this is open. In this Sonet element AIS
will be inserted that will prevent further alarming in the Sonet world. The
10GE receiver will receive the AIS. 

In case of legacy  WDM or OTN where you have non-intrusive monitors you will
have this alarms through al Translators and other NE up to the point where
this may hit a Sonet NE or the 10GE receiver. This LOF notifications again
may be interpreted as signal type mismatch so in particular if several
operator domains are passed may be interpreted as mis - connection.

OTN also ( expecting a Sonet signal but receives something different) will
interpret this as signal type mismatch and insert Unframed AIS which will
than be also delivered to the 10 GE receiver. (this will lead to LOF in this
receiver).

An issue with this pattern may be that the LOF process is slower than the K-
bytes interpretation for protection switching and such fixed pattern may be
interpreted as stable K-bytes and a protection action may be partly
initiated.  (By the way, this is a known issue and was also considered when
defining the Unframed AIS in OTN).

As said this is a potential trouble source in applications where you
transport this over an existing transport network using standardized
technology causing trouble and additional cost in operating this. It should
further be noted that all Sonet framing chips currently are able to generate
AIS (which I know as a very simple pattern) but do not support such static
patterns.
Regards Juergen



 

> ----------
> Von: 	Tom Alexander[SMTP:Tom_Alexander@xxxxxxxxxxxxxx]
> Gesendet: 	Donnerstag, 28. Juni 2001 20:26
> An: 	'DAWE,PIERS (A-England,ex1)'; Rahn, Juergen (Juergen);
> stds-802-3-hssg-serialpmd@xxxxxxxx
> Betreff: 	RE: [802.3ae_Serial] another question on pattertn defined in
> the  current draft:
> 
> 
> Juergen and Piers,
> 
> The decision to not send AIS upon loopback was made for the following
> reasons:
> 
> 1. During loopback, it is suggested that as much of the WIS functionality
> be tested (i.e., involved in the loopback path) as possible. Therefore,
> the WIS transmit process is expected to be completely occupied in
> processing
> the data being looped back to the PCS, and will not have any facility
> to send any type of SONET signal to the PMA. If a valid SONET AIS is
> to be sent to the PMA during loopback, then it will be necessary for the
> implementer to create an entirely separate subset of SONET framing
> functionality, active ONLY during loopback, for the sole purpose of
> transmitting AIS to the PMA. This was deemed by the WIS group as being
> an unnecessary and excessive burden on the implementer.
> 
> The alternative that has been specified in the WIS clause requires no such
> extra hardware; the 00-FF pattern can be sent to the PMA by simply forcing
> the PMA service interface to a fixed binary value.
> 
> 2. The constant pattern, originally 00-00 but now 00-FF, does not
> correspond
> to any SONET framing characters. Therefore, the far-end WIS will lose
> frame
> synchronization almost immediately when the local WIS has been placed into
> loopback. The effect will be similar to that of a failure of the WIS
> (loss of framing). This is precisely the logical effect upon the far-end
> WIS as a consequence of placing the local WIS into loopback; effectively,
> the transmit path of the local WIS has been disabled or shut off by
> putting
> it into loopback, and shutting off the WIS transmit path would have most
> likely raised an LOF alarm at the far-end under normal circumstances.
> 
> 3. Loopback is an administratively configured mode; i.e., a WIS cannot
> enter
> loopback in any automatic manner during normal operation. Therefore, some
> management entity must be aware that the local WIS is in loopback. This
> management entity is also hence in a position to ensure that the far-end
> WIS does not generate and propagate any false alarms or defects during
> loopback. If it is desired that false alarm conditions are not raised,
> the system designer is perfectly capable of implementing whatever
> suppression
> measures are required.
> 
> 4. The WIS can talk only to another WIS. This has been frequently stated,
> frequently emphasized, and is the underlying assumption behind the WIS
> clause. In fact, most of the first page of Clause 50 spends a great deal
> of verbiage explaining that the WIS is not SONET/SDH compliant and is not
> supposed to talk directly to SONET transport equipment. The WIS, as
> specified, permits only a Path Relay function within the context of the
> transport network; interfacing to SONET/SDH STEs or LTEs is outside the
> declared scope. Therefore, I do not understand why the pattern output
> during WIS loopback - which is certainly an abnormal and administratively
> configured condition - should be permitted to have any effect upon the
> transport network.
> 
> 5. From the point of view of the remainder of the network, placing a
> local WIS into loopback is logically equivalent to disconnecting it or
> powering it down. Why, then, should placing the WIS into loopback be
> treated any differently from disconnecting it (in terms of sending AIS
> or not)? The effect upon the transport network is the same.
> 
> 
> I hope the above answers your question as to why the WIS group selected
> a constant pattern during loopback as opposed to AIS. Loopback is already
> not all that simple, from a hardware implementation point of view, in a
> 10 Gb/s WIS device - I would hope that we would not make it even worse.
> 
> Best regards,
> 
> - Tom Alexander
> WIS Scribe
> 
> 
> -----Original Message-----
> From: DAWE,PIERS (A-England,ex1) [mailto:piers_dawe@xxxxxxxxxxx]
> Sent: Wednesday, June 27, 2001 9:20 AM
> To: 'Rahn, Juergen (Juergen)'; stds-802-3-hssg-serialpmd@xxxxxxxx
> Subject: RE: [802.3ae_Serial] another question on pattertn defined in
> the current draft:
> 
> 
> 
> Juergen,
> 
> Draft 3.0 had said "In this mode, ... the WIS shall transmit a continuous
> stream of all-zero data words to the PMA sublayer, and shall ignore all
> data
> presented to it by the PMA sublayer."  This meant zeroes on the line:
> zeroes
> where the header would be and zeroes where the payload would be.  I
> thought
> that this could lead to optical power glitches and/or chattering optics
> and
> even worse problems than you describe, so I suggested changing it to any
> balanced pattern.  It turns out that the pattern chosen by the group is
> being proposed for the square wave test pattern for WAN PHY.
> 
> That's the history: I'll let the SONET experts debate the merit of AIS,
> which I presume is balanced, or nearly so.
> 
> Piers
> 
> > -----Original Message-----
> > From: Rahn, Juergen (Juergen) [mailto:krahn@xxxxxxxxxx]
> > Sent: 27 June 2001 10:28
> > To: stds-802-3-hssg-serialpmd@xxxxxxxx
> > Subject: AW: [802.3ae_Serial] another question on pattertn defined in
> > the current draft:
> > 
> > 
> > Hi,
> > Can somebody help me to understand why the pattern in case of 
> > Loop back is set to 00-FF?
> > My question is was there a strong reason for this that I do 
> > not know. What I know is that there are some 
> > ugly effects possible with such pattern when the interface is 
> > connected to a Sonet or other type transport network.
> > I understand that at the last meeting some work has been done 
> > on this loop back facilities. Now I read in 
> > 50.3.9 Loopback:
> > ..............................................................
> > ..............
> > ...........................the WIS shall transmit a constant pattern
> > to the PMA sublayer, and shall ignore all data presented to 
> > it by the PMA sublayer. The pattern output to
> > the PMA transmit path at this time shall consist of a 
> > sequence of 8 logic zero bits and 8 logic one bits, form-ing
> > the 16-bit word 00-FF hexadecimal. No SONET overhead or fixed 
> > stuff shall be output to the PMA at this time.
> > 
> > 
> > While agreeing that the data incoming to the PMA sublayer 
> > should not be 
> > sent further such constant pattern is likely to generate some ugly
> > additional 
> > effects . So maybe this would lead to  undefined and miss 
> > leading alarms  
> > or( or even protection actions) in a possible transport network. This
> > transport 
> > network that can either be a plane Sonet transport network, but also a
> > traditional 
> > WDM network with Sonet non-intrusive monitoring or transport 
> > via an OTN. In all those 
> > cases the consequence on such patterns are not defined and 
> > the alarms that will 
> > be generated are likely to be miss interpreted. For instance 
> > it can be 
> > interpreted that a wrong signal is connected. In case a proper AIS is 
> > inserted however the transport network will react in the standardized 
> > way and no alarms (or even protection switches as worst case 
> > scenario) 
> > will be activated (which should not be done when a client 
> > equipment is in test mode). 
> > So can somebody help me with the reason for this pattern ( In 
> > contrast to a normal AIS
> > that would not generate such effects). If there is no 
> > particular overriding reason for this
> > I would strongly suggest  to take the AIS signal instead.
> > Regards Juergen Rahn
> > 
> > 
>