RE: Simple solution to terminate the discussion about SONET versus SDH

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Stephen,

Of course SDH and SONET are interoperable and can be interconnected. You buy
a gateway and it is done. 

I spoke about the fact that in the control plane we should know if a signal
is using the SONET "profile" or the SDH "profile". Otherwise you cannot
achieve automatically what you described hereafter.

If at one end you generate a J1 on 64 bytes with the SONET profile you need
to interpret it at the other end as specified in the SONET "profile", not
using the SDH "profile" on 16 byte format. You cannot assume that all
existing SONET boxes (speaking GMPLS or not) will know that the other end is
SDH. This is just one example. I think that this is now clear for everybody.

Also due to a lot of legacy boxes at the network periphery, SS conversion is
still needed somewhere. These legacy boxes will not speak GMPLS, but they
will be the source of paths that will fly over GMPLS clouds and that could
even be terminated on GMPLS nodes. When signaling the LSP (SNC) initiated on
a SONET cloud and terminated in an SDH could you need to go through a SS
conversion. So you need to make a distinction between the SDH and SONET
"profiles".

Having a the same LSP Encoding Type for SDH/SONET is not general enough and
will not cover the cases where some cloud ignore that the other end is SDH.
Having a different LSP encoding type for SONET and SDH is just identifying
the profile to use. It doesn't prevent you to request an SDH signal from any
box to any box, if supported. It doesn't prevent any interoperability.

By the way we could may be add to your list other possible differences in
J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a list
from a tutorial without checking in details.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Tuesday, February 26, 2002 4:22 PM
To: Mannie, Eric
Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert);
'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; 'Kireeti Kompella'
Subject: Re: Simple solution to terminate the discussion about SONET
versus SDH


Eric,
I don't think you ask quite the right question.
The right question is:
Can all frame structures which are common to SONET and SDH be
interconnected,
and do they interoperate? This is what we care about from the viewpoint of
establishing switched connections.
The answer to this is YES.

Are they fully identical from all points of view? As Juergen says, this is
the
tricky question, as the answer of "No" might mislead some into thinking that
these signals cannot be interconnected between SONET and SDH. This is not
the case.

For those who care, some of the key differences are as follows. Note that
these
do NOT affect the ability to interconnect these signals (although sometimes
there
are rules about HOW to interconnect them).

SS bits - In the past, this was an issue in the high order pointers. SDH
sent
and expected "10", for SONET these bits were unspecified. This problem was
corrected
a few years ago by requiring that ALL equipment send "10" and ignore the
incoming
bits. Note that even prior to aligning the standards, a great deal of the
older
equipment followed this strategy as VC-4s and STS-3cs were interconnected
long
before the standards alignment.

Trace identifier - For J1, within SONET, a 64 byte format is normally used.
For SDH,
a 16 byte format is normally used. SONET specifies that in the case that the
far end
is SDH, a 16 byte format should be used to allow interworking. For J2, this
is normally
used in SDH and not normally in SONET. Interworking is acheived by having
the SDH end
ignore the incoming trace identifier (a required capability in the
standards).

RDI - SONET uses some extra bits that are reserved in SDH to further
classify far end
alarms (called ENHANCED RDI). This provides no obstacle to interworking: The
SONET
side will not be able to provide a more detailed classification of SDH end
alarms (it
does know there is a far end alarm). The SDH end ignores the extra bits. The
Enhanced
RDI feature only operates if both ends are SONET.

BIP - The coding for BIP is identical. The way degrade is detected is
different.
SONET generally uses a Poisson algorithm to declare degrade and SDH normally
uses
a bursty error detection algorithm. This provides no obstacle to
interconnect - the
criteria for declaring dDEG is just slightly different. Also, SONET provides
an
EXC alarm for BER > 10^-3 which does not appear in SDH. This also does not
prevent
interconnect - you just have an alarm which can be declared at one end and
not the
other.

These are the major differences (besides the fact that SONET and SDH tend to
have
different names for identical things- This is just a US/Europe language
issue).
Regards,
Steve

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> There is an easy way to stop definitively this discussion based on
technical
> facts:
> 
> Stephen, Juergen and Maarten, please tell us: today, are the frame
> structures and all the bytes in the SDH and SONET overhead completely
> identical, used and interpreted in the same way, is the monitoring exactly
> the same ? In particular, if I provision and operate an SDH circuit/LSP is
> this fully identical to a SONET circuit/LSP from *all* point of views ?
> 
> PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at this
> stage.
> 
> If the answer is yes: SONET is totally identical to SDH.
> If the answer is no: SONET is not the same as SDH.
> 
> I think that without that answer we cannot take any *technical* decision
on
> this mailing list and at the IETF.
> 
> Thanks to answer.
> 
> Kind regards,
> 
> Eric
> 
> ps: feel free to forward this e-mail to any ITU-T mailing list if a
> confirmation is needed.