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

["Bernstein, Greg" <GregB@ciena.com>]

To avoid re-grooming either virtual concatenation or arbitrary concatenation
can help, but the implications are quite different.
Say we have a particularly valuable (expensive) link that we can't or don't
want to re-groom then we have two options:
(1)	Require that ALL end systems that could potentially use this link
convert over to virtual concatenation from standard concatenation.
(2)	Or, install boxes at both ends of the link that support the
arbitrary concatenation that we've been discussing.

Which of these seems more realistic and practical?
Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237


		-----Original Message-----
		From:	Zhi-Wei Lin [mailto:zwlin@lucent.com]
		Sent:	Thursday, May 17, 2001 8:41 AM
		To:	Bernstein, Greg
		Cc:	'Maarten Vissers'; Anup Tirumala;
ccamp@ops.ietf.org; chickoo66@yahoo.com; ip-optical@lists.bell-labs.com;
t1x1.5; q11/15
		Subject:	Re: [IP-Optical] concatenation extensions in
sonet/sdh

		Hi,

		some observations:

		in terms of re-grooming and such, I believe both virtual
concatenation
		and arbitrary concatenation can perform this. One method is
		standardized, the other is proprietary.

		In terms of routing of the individual connections that make
up the
		concatenated signal, virtual concatenation is more flexible
than
		arbitrary concatenation, since you can put each component VC
in
		different lines, and each component can be routed
differently.

		In terms of interworking, yes the SIGNALLING can defnititely
be made to
		interwork. However, the larger issue for interworking is
support by the
		transport equipment themselves. Thus interworking involves
TWO parts:
		signaling interworking and transport interworking. Having
one without
		the other doesn't really help...

		Thus, in terms of solving real problems, either virtual or
arbitrary can
		accomplish that, but IMO, virtual seems more flexible...and
		standardized...

		In terms of standards as fostering interoperability and
stifling of
		innovation, in principle yes I agree. And therefore if
arbitrary
		concatenation should be standardized, it should be
standardized in the
		correct standards body. As Maarten mentioned, the relevant
standards
		bodies discussed arbitrary concatenation years ago, and
decided
		(hopefully based on their expert technical opinion - I
wasn't involved)
		not to include arbitrary but instead to include virtual.
IMO, there must
		be good reasons, and from what I can tell, I see virtual as
been more
		flexible so that is a pretty good reason...we at IETF, being
protocol
		experts (and budding transport experts?) should not try to
second-guess
		the decisions without fully understanding the
ramifications...

		As for stifling innovation, anytime you standardize anything
there is
		always some factor of development that gets fixed (is this
something
		that should not be said in a public forum??? -- sorry!!).
Therefore
		there is always a tradeoff between innovation and
standardization. I
		think the job of standards bodies is to try to balance these
two factors
		such that the industry in general can live with the result
without
		unduly burdening...

		agree?

		Zhi



		"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.
		> (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.
		> 
		> 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.
		> 
		> 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.
		> 
		> 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.
		> 
		> Greg B.
		> 
		>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
		>         New phone: (510) 573-2237
		>