[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
- To: "'Lazer, Monica A, NNAD'" <mlazer@att.com>, 'Zhi-Wei Lin' <zwlin@lucent.com>
- Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
- From: "Bernstein, Greg" <GregB@ciena.com>
- Date: Thu, 17 May 2001 11:52:25 -0700
- Cc: 'Maarten Vissers' <mvissers@lucent.com>, Anup Tirumala <Anup@jasminenetworks.com>, ccamp@ops.ietf.org, chickoo66@yahoo.com, ip-optical@lists.bell-labs.com, "t1x1.5" <t1x15@t1.org>, q11/15 <tsg15q11@itu.int>
- Delivery-date: Thu, 17 May 2001 11:55:55 -0700
- Envelope-to: ccamp-data@psg.com
Are we having fun for a Thursday, or what?
Zhi, had me convinced that I should do a "start up" specializing in virtual
concatenation for link bandwidth optimization, then Monica asked me about
overhead use in arbitrary concatenation...
Here are some more points:
(1) Arbitrary concatenation (assuming standard sizes) is fairly minor
tweak of standard contiguous concatenation, i.e., the framer just needs to
be told the starting time slot (which has the pointer) and the remaining
(arbitrary) time slots (which have the concatenation indication set). No
path overhead is used for this process. It is strictly a line level
operation, e.g., B3 is not recalculated. This is suitable for LTE equipment
and has nice consequences for avoiding re-grooming.
(2) Virtual concatenation is a whole new and useful feature that uses
path level overhead, in particular the H4 byte. Hence the path level BIP B3
needs to recalculated. This is more a PTE (path termination equipment) kind
of thing to do. Not something that a typical switch would necessarily want
to do for compatibility purposes. This was intended for a much more
sophisticated application, i.e., a path level "bonding" or inverse
multiplexing, but it lacks path level transparency if used to avoid
regrooming.
Hope this puts some more gasoline (petrol) onto the fire.
Greg B.
Dr. Greg M. Bernstein, Senior Scientist, Ciena
New phone: (510) 573-2237
-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
Sent: Thursday, May 17, 2001 11:01 AM
To: Bernstein, Greg; '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: RE: [T1X1.5] RE: [IP-Optical] concatenation
extensions in sonet/s dh
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
>