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

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

Why don't we just remove the contiguous arbitrary concatenation from the
GMPLS specification  since it's not standard and doesn't offer any value
that I can see.  Anything else could be left for peoples proprietary
extensions:-)

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237


		-----Original Message-----
		From:	Steve West [mailto:Swest@turinnetworks.com]
		Sent:	Thursday, May 17, 2001 12:52 PM
		To:	'Stephen Trowbridge'; Bernstein, Greg
		Cc:	'Zhi-Wei Lin'; '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

		Greg:

		It seems that you have a scheme that allows better
utilization of a link by
		including a new type of concatenation hardware, just at the
ends of that
		link.  If I understand, the concatenation method allows you
to remove the
		requirement for "contiguous" sts1/columns in the SONET/SDH
payload, by
		"leap-frogging" over columns that are in-use and thus
"in-the-way" ?  

		If my read is right, why not also present this "leap-frog"
arbitrary
		concatenation scheme to the relevent standards authorities
(ANSI/ETSI/ITU),
		so that the experts there can validate its applicability?

		Steve West

		-----Original Message-----
		From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
		Sent: Thursday, May 17, 2001 11:39 AM
		To: Bernstein, Greg
		Cc: 'Zhi-Wei Lin'; '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


		There is no intent in any of the standardization bodies to
stifle
		innovation. Standards are contribution driven, and what you
find
		in the documents as written are the product of those
contributions.

		If the desire is to extend current SONET/SDH with an
arbitrary
		concatenation feature, there is no problem to contribute to
T1X1
		and/or ITU-T to propose this extension. This is the correct
way to
		approach it. The INCORRECT way is to confuse the market by
producing
		an IETF version of SONET/SDH specs that is different from
T1X1/ITU-T.

		Let me add some background on how we ended up with the
current
		situation recommending virtual concatenation in SONET/SDH:

		1. Contiguous or Arbitrary concatenation requires
implementation
		of the concatenation method at every NE along the chosen
path
		through the network to provide a service. At the time we
began
		these discussions, we had the problem that ATM wanted to use
		VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
		links in the network and NEs that didn't support trails
		bigger than VC-4 (STS-3c). By now, of course, VC-4-4c
(STS-12c)
		and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
		but as has been observed in previous emails, it will be a
		long time before you replace all of the 2.5G links in the
		network, so contiguous/arbitrary concatenation to greater
		than VC-4-16c/STS-48c is still a problem for some time to
		come. The endpoints in a network always seem to evolve ahead
		of and faster than links and equipment in the core network
		can be replaced, so it was important to define a
concatenation
		method that could be implemented only by the endpoints.

		2. Contiguous/arbitrary concatenation is not as elgant for
		lower order paths as for higher order paths. We saw in
		a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
		into an STM-1, but most equipment does not provide the
		ability to concatenate lower order paths. For certain
		payloads, lower order paths fit better, e.g., 5 x VC-12
		to carry 10Mb Ethernet.

		3. Different payloads to not fit ideally into "standard"
		multiples found in contiguous concatenation (4, 16, 64,
		256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
		fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

		4. As paths are set up or taken down in a network, there is
		a tendency for capacity to become fragmented. Contiguous/
		arbitrary concatenation cannot always take advantage of
		free timeslots along a span if they are not adjacent on
		the same fiber or if they are on different fibers.

		5. LCAS was easier to envision in a virtual concatenation
		environment. Many of the new services are not inherently
		constant bit rate, and it can be useful to dynamically
		add or remove components of the bundle to adjust link
		capacity. It is also useful to be able to handle failures
		of individual components of the concatenated trail by
		just reducing the capacity rather than by having to
		protection switch the entire path.

		Virtual concatenation was designed to solve all of the above
		problems. Arbitrary concatenation is another way to solve
		problem (3) above, but it doesn't solve the others. Given
		that virtual concatenation is standardized to solve all
		of the problems, it reduces the pressure to implement
		arbitrary concatenation throughout the network to solve
		only problem (3).

		If problem (3) is the only one you are trying to solve,
		arbitrary concatenation has the advantage of not requiring
		so much buffer space at the endpoints to accomodate
		differential delay. But with trends in memory costs, this
		is not so much of an issue, and this needs to be traded
		off against the need to provide support for the contiguous/
		arbitrary rate and all associated protection mechanisms at
		EVERY NE along the chosen path in the network in order for
		this to work.

		If there is a significant market for applications where
		solving (3) is vital but (1,2,4,5) are not so important,
		then it may be worth pushing arbitrary concatenation as
		a way to optimize how those services are provided over
		what you get with virtual concatenation.

		Regards,
		Steve Trowbridge

		"Bernstein, Greg" wrote:
		> 
		> 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
		>                 >