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

["Lazer, Monica A, NNAD" <mlazer@att.com>]

Why wouldn't the 2 boxes in option 2 use virtual concatenation instead of
arbitrary concatenation, though?

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
mlazer@att.com


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

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
                >