Re: [T1X1.5] Re: [IP-Optical] concatenation extensions in sonet/sdh

[Maarten Vissers <mvissers@lucent.com>]

Greg,

Comment in-line:

"Bernstein, Greg" wrote:
> 
> Hi Huub, see the comments in line below. But first, a couple of points (as
> usual):
> (1)     Virtual Concatenation is a great feature in SONET/SDH and I'm very
> much for it and I think it has a lot to offer.
> (2)     Arbitrary Concatenation means (to me) three things: (a) arbitrary
> size - don't know that this is that useful in a general network-(b)
> arbitrary starting time slot, (c) arbitrary locations of successive
> timeslots.
> (3)     If we use arbitrary concatenation but restrict to standard sizes,
> then we have the capability to avoid regrooming on a link by link basis
> (note that the arbitrary placement doesn't preclude a restriction to
> standard timeslot usage.
> (4)     In line with Eric's comment do we want the signaling protocol to
> include standard practice, possibly standard practice, features offered by
> one quarter of the vendors, etc... Or strictly what is standardized?
> Switching based on path groups certainly isn't in any standard (its not
> precluded)but a few vendors provide it so we put it in. 

Given the discussion on arbitrary concatenation and the clear request
not to redefine SONET/SDH in the control plane specification, I would
like to apply it to all SONET/SDH extensions... including the one that I
proposed (AUG-X/STSG-X) and the one already present (and my trigger)
TUG-X/VTG.

I will have to propose to Q.9/15 (responsible for G.783) to define an
additional MSn/Sn_A function which will be capable to support the AUG-X.
Note that there is no need to extend G.707 (or T1.105) for this feature.
It is a pure SDH/SONET equipment issue (i.e. G.783).

> The additional
> transparency feature was requested so we put it in (some of us put in a
> bunch of work to fix it up from its initial form, even if we would have
> preferred its deferal). 

Also this extension of SONET/SDH should not be included, unless it is
supported by G.707 and T1.105.

> Hence it was my notion that we were making the
> signaling specification a common language and not trying to redefine
> SONET/SDH standards (which should aim for the least common denominator in
> some sense.  BTW how did that extreme layer violation of in-band FEC get in
> the OC-192 spec?).

If you look at the FEC model in G.783, you will notice that there is no
layer violation. The FEC processing is part of the RS/MS adaptation
function, and to support it two new adaptation functions have been
defined RSn/MSFn_A and RSn/MSn-fec_A (see 10.3.6/G.783 10/2000). Note
that the existing RSn_TT and MSn_TT functions haven't been modified at
all.

Regards,

Maarten
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard