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

[Dimitri.Papadimitriou@alcatel.be]

That's probably the issue here, i see lot of response with respect
to the last status that has been achieved over years at bodies like
the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet 
and SDH; the option (2) doesn't at all preclude this, it give us the 
capability to have a more pragmatic evolutionary scenario. That's 
also the paradox, i see people coming from the transmission world 
having an idealistic view on transmission networks (and control plane)
while they know it will take years to achieve full interop; this while
others have a real pragmatic view on what short/mid-term needs are/
will be. 

The option 2) takes into account current install base (with GMPLS 
soft update) and future needs - we don't even have to discuss in 
detail here the specifics btw Sonet and SDH overhead and corr.
processing - if the "SHOULD" must have to be clarified then let's
go for it.

rgds,
- dimitri.

"Mannie, Eric" wrote:
> 
> 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.

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1 
         B-2018 Antwerpen, Belgium
Phone:   Work: +32 3 2408491 - Home: +32 2 3434361