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

[Maarten Vissers <mvissers@lucent.com>]

Greg,

> Other applications do exist and are somewhat competitive with non-LCAS
> virtual concatenation since the implementation of arbitrary concatenation
> for odd sized signals is simpler than that of virtual concatenation.  Once
> "odd" sized signals are used an entire path through the network must exist
> that supports them.

I do not understand the sentence above. Using virtual concatenation,
"odd" sized signals (e.g. a VC-4-11v) require that only the two
endpoints (where you terminate the "odd" sized signal to access the
client signal in the payload) must be aware of the "odd size". All the
rest of the equipment inbetween the two endpoints doesn't have to be
aware of the odd size at all, as they only see a normal basic size (e.g.
11x VC-4).

Using arbitrary concatenation, "odd" sized signals (e.g. a VVC-4-11a
("a" to represent "arbitrary concatenation")) require that the two
endpoints and all intermediate STM-N/OC-N ports must be aware of the
"odd size". The AU/STS pointer processors in those STM-N/OC-N ports must
first support this arbitrary concatenation (AU-4-Xa, STS-Xa), and
besides this need to be provisioned specifically with the AU/STS time
slots that are occupied by the AU-4-Xa, STS-Xa.

For the network therefore virtual concatenation is simpler than
arbitrary concatenation. 

Other comments are below:

"Bernstein, Greg" wrote:
> 
> A couple more points.
> (1)     GMPLS works well with arbitrary concatenations need to specify the
> time slots since it provides a signaling protocol that can do just that,
> i.e., GMPLS actually enables this feature to interoperate.
> (2)     Arbitrary concatenation offers a solution to a real problem, i.e.,
> eliminates the need for re-grooming on lines that support it.  For those who
> have invested non-trivial amounts of money in transoceanic links this can be
> a significant savings.

I agree that a HOVC/STS cross connect supporting arbitrary concatenation
at its line ports facing the cable prevents the need for bandwidth
defragmentation. It's nice if you have it, but investigations I was
involved in in the past weren't seeing fragmentation as a real problem.
It wasn't something that had to be done on a daily basis... But the
situation may have been changed since then...

> (3)     The goal is interoperability and to solve real problems.  We've got
> a real problem and with a minor edit to the GMPLS SONET specification we can
> have an interoperable method for solving it.

The "real problem" seems to be focused on the transatlantic cable where
the grooming function in the head end cross connect takes the
standardised regular STS/HOVC signals from the terrestrial network and
forwards those onto the cable. This is a network internal optimisation,
in essense invisible to the "outside world"; i.e. the UNI or E-NNI would
not show the details of this to the other networks of
customers/operators.

> 
> To be precise in the definition of arbitrary concatenation:
> As a concatenated signal within a single SONET Line (SDH MS), with
> potentially arbitrary timeslots used for its components.
> 
> The current main application is: avoiding the need for service impacting
> re-grooming. Note that this applies to standard sized signals and is a per
> link property.

If it is per link proprietary, it is by definition not part of a
standard interface; and thus there is no need to show it in a standard
control plane message. The proprietary link simply supports the standard
STS/HOVC link connection types; in addition it will not have the
"blocking" effect a regular link may have when it gets fragmented and
isn't able to quickly perform a link defrag operation. It also implies
that the rules for the "pamXXX" link parameters (see G.85x and other
email correspondence) will be somewhat different.

> 
> Other applications do exist and are somewhat competitive with non-LCAS
> virtual concatenation since the implementation of arbitrary concatenation
> for odd sized signals is simpler than that of virtual concatenation.  Once
> "odd" sized signals are used an entire path through the network must exist
> that supports them.

See begin of this email.

> 
> Folks I thought the role of standards organizations was to foster
> interoperability that enables the industry to move forward rather than as a
> means to stifle innovation. I think it is better for the marketplace to
> decide which features are desirable.

Indeed standards are to foster interoperability. And it is a serious
interoperability concern that is causing this reaction from me. About a
year ago all members of ITU-T and T1 agreed to remove arbitrary
contiguous concatenation from the T1.105 and G.707 standards to prevent
another serious interoperability issue to be introduced into the world
wide SONET/SDH network. This to provide a clear indication to the client
equipment (e.g. IP router, ATM switch, ethernet switch) manufacturers
that the SONET/SDH network doesn't support such arbitrary contiguous
concatenated STS/VC-4 signals. And it is for this reason somewhat
"inappropriate" to revert this indication in a transport network control
plane specification. This would be a clear inconsistency, and
inconsistencies only cause trouble for all parties...

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