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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

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
>                 >