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

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

Hi Mike consider the case with standard sizes and but potentially
non-standard timeslots. A box that can use arbitrary concatenation and
restricts itself to standard concatenation when dealing with boxes that
don't support arbitrary concatenation. But links that do support arbitrary
concatenation (standard sizes, any slots) do not have to worry about
re-grooming.

I agree with you that for general interoperability when one wants
non-standard sizes one should use Virtual Concatenation.
GB
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237


		-----Original Message-----
		From:	Mike Scholten [mailto:mscholte@amcc.com]
		Sent:	Thursday, May 17, 2001 10:14 AM
		To:	Zhi-Wei Lin
		Cc:	Bernstein, Greg; '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

		 << File: Card for Michael Scholten >> Greg, Zhi:

		A more important consideration that seems to be lost
(although Maarten made the point), is that intermediate nodes may not
		accept and handle "arbitrary concatenation," where arbitrary
is defined as STS-nc with n != 3, 12, 48, 192, 768.  Many pointer
		processors in these intermediate nodes, upon examining the
H1, H2 bytes where the concatenation indicators exist, will declare
		Loss-of-Pointer (LOP) when an unrecognized "arbitrary
concatenation" pattern is seen, causing the path to be declared as failed,
		initiating a protection switch.  In order to support
arbitrary concatenation, equipment in these intermediate nodes would also
		have to be replaced.

		No intermediate node equipment needs to be replaced to
support virtual concatenation, since member paths are simply routed as
		STS-1 or STS-3c paths.

		All of the above comments apply to ITU equivalents (e.g.
arbitrary concatenation would be defined as VC-4-nc with n != 4, 16,
		64, 256;  VC-path member paths simply routed as VC-3 or VC-4
paths).

		Regards, Mike

		Zhi-Wei Lin wrote:

		> Hi Greg,
		>
		> Let me change a few words in your example:
		>
		> > (1)     Require that ALL end systems that could
potentially use this link
		> > convert over to arbitrary concatenation from standard
concatenation.
		>                   ^^^^^^^^^
		> > (2)     Or, install boxes at both ends of the link that
support the
		> > virtual concatenation that we've been discussing.
		>   ^^^^^^^
		>
		> I think the two example are different. #1 talks about
potentially use
		> the link. That's also true of arbitrary or virtual.
		>
		> #2 talks about only a pair of endpoints that support this.
That's also
		> true of either virtual or arbitrary.
		>
		> Another observation:
		>
		> Arbitrary or virtual concatenation only impacts the
endpoints, and for
		> any application either concatenation method would impact
the same
		> endpoints, and therefore would require the same amount of
change of the
		> endpoints.
		>
		> Example:
		>
		>  +-----+   +----+    +----+    +----+    +--------+
		>  | A   |---| B  |----| C  |----| D  |----|    Z   |
		>  +-----+   +----+    +----+    +----+    +--------+
		>      \                                    /
		>       \                                  /
		>        \   +----+    +----+    +----+   /
		>         \--| E  |----| F  |----| G  |--/
		>            +----+    +----+    +----+
		>
		> Assumes a VC-4-3c (or VC-4-3v) is requested.
		>
		> With arbitrary concatenation, each component can be placed
in any
		> timeslot, but they all traverse A-B-C-D-Z or A-E-F-G-Z. A
and Z needs
		> special functions. But since you mentioned that arbitrary
concat assumes
		> that the timeslots are sequential ordered (i.e., info in
timeslot 1-6-8
		> cannot be rearranged 1-8-6), the intermediate nodes need
certain
		> constraints on re-ordering (constraining the TSI
capability).
		>
		> With virtual concat, each component can be placed in any
timeslot, and
		> each component can travel different routes, so timeslot 1
& 8 can
		> traverse A-B-C-D-Z while timeslot 6 can traverse
A-E-F-G-Z. A and Z
		> needs special functions. However, as each timeslot is
treated as a
		> separate connection, the intermediate nodes do not need
any info or
		> constrained. The A node, when deciding the route (source
routing) will
		> take the differential delays into account. And according
to Maarten's
		> previous email, current state-of-the-art can handle
differential delays
		> where the differential path distance between two component
can be up to
		> 3000 km (was this the right figure???) -- 3000 km is quite
a bit
		> DIFFERENTIAL distance.
		>
		> Hope this helps with the discussion...
		>
		> Zhi
		>
		> "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
		> >                 >