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

[Dimitri.Papadimitriou@alcatel.be]

Stephen,

imho, i don't think the issue is when interop is there at the 
transport plane level; the issue is when interop is not there 
at the transport plane level and one tries to achieve abstract
uniformity at the control plane level. This generates control
processing changes within the current implementation since you
will imply a negotiation phase prior to the connection setup.
(refer to the example provided by Eric, for instance); so, the 
key issue is to know if the current "profiles" are enough in 
order to avoid this additional signalling message exchange.
That's what i call "pragmatic evolutionary scenario", in brief
put additional implementation efforts where needed at the time
they are needed; here your option would have to be translated 
into additional message implementation and coding, and i am 
not so sure, that compared to adding additional values for an
existing structure (ie the label) you are promoting the most
pragmatic solution.

Hope this clarifies,
- dimitri.

Stephen Trowbridge wrote:
> 
> Dimitri,
> Perhaps we were not precise enough in spoken language in reaching
> our "agreement" in SLC. We discussed that we would use the SDH coding
> in the cases where we had identical multiplex structures between
> SONET and SDH. I came away thinking that this translated to "shall",
> and obviously some others thought it translated to "should". For
> those of us who understood "shall", we then move to the followup
> discussion that SONET is a subset of SDH and therefore there are no
> cases where a SONET multiplex structure exists that is not also
> in SDH, so we use only SDH codings (leaving aside the VT3 case
> which is not real, and if it were, would be added to G.707).
> 
> By "pragmatic evolutionary scenario", it seems that you are proposing
> to leave in place dual codings that impede interworking to preserve
> or protect pre-standard implementations. I believe that the purpose
> of a standard is to allow interworking, not to protect pre-standard
> implementations.
> 
> In an earlier email of Eric's, I see also:
> > If we give you a solution that does what you want to do, plus in addition
> > what some other people want to do, why are you complaining ????
> I am complaining because a document that simply lists all of the different
> things that different people want to do is not a standard - it is just a
> catelogue of everyone's proprietary choices. To have a standard, you
> make a choice and write it down so you can interoperate.
> Regards,
> Steve
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > 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

-- 
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