[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simple solution to terminate the discussion about SONET versu s SDH
Eric,
the point is that you cannot say SONET uses all these overhead options and SDH uses all the other overhead options. So no specific SONET and SDH profiles exist, both can come with a mixture of OH options. You find for example for both equipment that supports only an one byte J0 or equipment that supports a 16 byte J0 string. SDH as a superset covers the SONET definitions.
Saying just SONET or SDH doesn't provide interworking at all.
Regards
Juergen
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Tuesday, February 26, 2002 5:31 PM
> To: 'Stephen Trowbridge'
> 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
> versu s SDH
>
>
> 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.
>