Subject: Re: Re: draft-ietf-pwe3-sonet-00

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Aug 2002 09:42:29 +0200

For the case virtual concatenation is used to transport data signals (e.g.
Ethernet over SDH/SONET), typically 50% of the bandwidth is sent via one route
and 50% via another route. 
	Note - This allows to keep connectivity when a fault in one of the
	routes exists (however with lower bandwidth). This is controlled via
	the LCAS protocol at the two virtual concatenated endpoints.
The differential delay between the two routes must now be within limits. 
Today's implementations support at STS level a maximum differential delay of 16
ms (i.e. 32 ms buffer). For normal SDH/SONET networks this is equivalent to a
route difference of about 3000 km (each SDH/SONET HOVC/STS network element has a
transfer delay of about 10-15 us only, and the effect on transfer delay can be
neglected). 

The use of a 15 ms buffer in STSoverMPLS can't be neglected. In case of
STS-1-Xv/STS-3c-Xv over MPLS, the differential delay through the MPLS network
for the two groups of X/2 STS-1/STS-3c signals must be controlled and limited.
Otherwise STSoverMPLS can't be used for the transport of STS-n-Xv signals.

Regards,

Maarten

Ron Cohen wrote:
> 
> Mudhafar,
> 
> I'd like to add to David's and Andrew's points that the fractional
> STS-1/VC-3/VC-4 encapsulation described in
> draft-ietf-pwe3-sonet-vt-00.txt provide the ability to carry multiple
> VT1.5/2 (VC-11/12) together within a single circuit emulation flow. This
> solves the problem of variable delay when sending individual VT emulated
> flows across the PSN, without paying for bandwidth (A VCG containing 8
> VT1.5s can be carrying within one fractional STS-1 emulated circuit,
> without paying for the bandwidth of the other 20 VTs normally carried in
> a full STS-1). This application is described briefly in
> draft-cohen-pwe3-tdmsonetapp-00.txt.
> 
> Ron
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of David Zelig
> > Sent: Tuesday, August 27, 2002 10:24 AM
> > To: 'Mudhafar Hassan-Ali'
> > Cc: [email-masked]; Andrew G. Malis
> > Subject: RE: [PWE3] Re: draft-ietf-pwe3-sonet-00
> >
> >
> > Mudhafar,
> > For your first question, there are two aspects:
> > 1) In terms of encapsulation there is no need to handle it
> > since virtual concatenation is a protocol between the path
> > termination points, and the draft mechanism does not require
> > path termination functionality.
> > 2) In terms of delay variation between the individual paths
> > in the VCG, you need to make sure that the edges of the VCG
> > can handle the delay difference between two individual paths
> > that may be subject to different emulation paths with
> > different de-jitter buffer setting etc. This is however out
> > of the scope of the draft.
> >
> > David
> >
> > > -----Original Message-----
> > > From: Mudhafar Hassan-Ali [mailto:[email-masked]]
> > > Sent: Tuesday, August 27, 2002 12:11 AM
> > > To: Andrew G. Malis
> > > Cc: [email-masked]
> > > Subject: [PWE3] Re: draft-ietf-pwe3-sonet-00
> > >
> > >
> > > Andy,
> > >
> > > 1. I checked them, they don't seem to refer to that.
> > > 2. How many switches/routers were there in the path that gave
> > > 15 msec? I agree
> > > with you there are a lot of work done in the literature in
> > relation to
> > > synchronization over packet networks. But what is different
> > > here is to maintain
> > > the tight synchronization of stratum 3 or better.
> > >
> > > Regards,
> > > Mudhafar
> > >
> > > "Andrew G. Malis" wrote:
> > >
> > > > Mudhafar,
> > > >
> > > > 1. See if draft-pate-pwe3-sonet-vt-00.txt meets your needs,
> > > and if not
> > > > you're certainly welcome to propose new text to either or
> > > both drafts.
> > > >
> > > > 2. The SONET draft is aimed at STS-1 and above and mainly
> > > for when a common
> > > > timing reference is available at both ends of the circuit.
> > > Sections 3 and
> > > > 6 in the draft address the synchronization and jitter
> > issues in the
> > > > fidelity of the emulated service.  In our own
> > > implementation, we've found
> > > > so far in practice that a 15 ms receiver buffer is
> > > sufficient to provide an
> > > > excellent quality service when used in conjunction with an
> > > appropriately
> > > > traffic engineered path through the network.  For
> > > lower-rate services,
> > > > there have been any number of papers on how well AAL1 can
> > > carry DS1 and DS3
> > > > services that may be instructive and generalizable for
> > > other PSNs besides
> > > > ATM.  You might want to do an IEEE Network or IEEE
> > > Proceedings literature
> > > > search.
> > > >
> > > > Cheers,
> > > > Andy
> > > >
> > > > ------
> > > >
> > > > At 8/26/2002 01:37 PM -0700, Mudhafar Hassan-Ali wrote:
> > > >
> > > > >Andy,
> > > > >
> > > > >In reference to draft-ietf-pwe3-sonet-00 (July 2002), I have the
> > > > >following comments:
> > > > >
> > > > >1. It seems a need to include virtual concatenations in
> > > addition to the
> > > > >contiguous concatenations in SONET/SDH.
> > > > >2. Has any one done simulation or mathematical modeling
> > > for the time
> > > > >synchronization issues when STS/VT/DS1/DS3 are carried
> > over packet?
> > > > >
> > > > >Mudhafar
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3