[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] concatenation extensions in sonet/sdh
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
-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Thursday, May 17, 2001 1:36 AM
To: Anup Tirumala
Cc: chickoo66@yahoo.com; Bernstein, Greg;
ip-optical@lists.bell-labs.com; t1x1.5; q11/15
Subject: Re: [IP-Optical] concatenation extensions in
sonet/sdh
<< File: Card for Maarten Vissers >> Greg, Anup, Sanjay,
To my recollection, the SONET/SDH definition is performed in
T1X1.5 and
ITU-T SG15. Last year new revisions of T1.105 and G.707 were
approved,
in which the "arbitrary contiguous concatenation" has been
removed. Such
step isn't made just for fun.
If you believe the removal of "arbitrary contiguous
concatenation" from
these standards was a mistake, please submit a contribution
to T1X1.5
and ITU-T Q.11/15 with a proposal to re-introduce it. At the
same time
you can then also request to introduce "arbitrary
concatenation" and
propose mappings of client signals into these arbitrary
(contiguous)
concatenated signals. However, as indicated by Mark, Juergen
and myself,
I doubt if you find support for such extension of SONET and
SDH.
For the moment, SONET/SDH networks compliant with T1.105 and
G.707
standards can forward "contiguous concatenated" VC-4-Xc
(X=4,16,64) and
STS-3c/12c/48c/192c signals and "virtual concatenated"
VC-n-Xv (n=3,4),
STS-1, STS-3c-Xc (X=1..256) and VC-n (n=11,12), VT-1.5-Xv
(X=1..64)
signals, not the "arbitrary concatenated" signals.
Arbitrary concatenation is a proprietary extension of
SONET/SDH, for
which there is no interworking with standard SONET/SDH
networks.
Virtual concatenation is THE international standardised
direction, for
which a vendor and operator may expect to see seemless
interworking in
the SONET/SDH network.
Virtual concatenation got very popular due to the:
- pricing of Ethernet ports on routers (compared to pricing
of
STM-N/OC-N ports on routers),
- absence of channelized STM-N/OC-N interface ports on
routers.
As a result the transport network was forced to accept
Ethernet physical
interfaces, in additon to the traditional SONET/SDH and PDH
interfaces.
Transport networking engineers very well understand the
desire of a
customer to pay only for the bandwidth needed, and
consequential within
the constraints of the SONET/SDH transport network a
solution was
developed to meet the needs of the customer and the needs of
the
operator. This is virtual concatenation with GFP as
encapsulation
method.
Virtual concatenation allows to separate the physical and
logical
aspects of Ethernet signals, like such is common practice
for any other
SDH/SONET signal. I.e. the (10M, 100M, 1G) Ethernet PHY
signal is
terminated, the ethernet idle packets are dropped and the
packets with
information inside of it are forwarded in a transport pipe
sized to the
customers need.
The additional complexity is the introduction of a (skinny)
ehternet
layer on top of the SDH/SONET layers, as at a minimum some
monitoring is
to be performed at the ethernet level.
Of course, it would be more economical if the transport
network didn't
have to do this job. I.e. routers should use STM-N/OC-N
interface ports
supporting virtual concatenated VC-n/STS/VT signals. The
transport
network would n't have to deal then with its client signals,
and instead
of ethernet in the virtual concatenated signals, any other
data protocol
could be used by the routers (e.g. IP/PPP/GFP).
But, while having to do this ethernet processing, extensions
are
becoming economical in the access transport networks; i.e.
having
ethernet bridging/switching present, it can be used to groom
ethernet
traffic to further optimise and thus cost reduce ethernet
packet
transport. It is now possible to offer sub-VC-n/STS/VT
ethernet
transport pipes (in addition to the multi-VC-n/STS/VT )
through the
SDH/SONET access networks.
Regards,
Maarten
Anup Tirumala wrote:
>
> If routers can routinely fill TDM pipes fully, why are we
even talking
> virtual concatenation?
>
> Arbitrary (or even Virtual) concatenation has the
> best bang for buck with packets sharing bandwidth
> with TDM. (i.e. in a converged network).
>
> Indeed, a business case does exist for arbitrary
concatenation.
> Ask Cyras (now Ciena;)
>
> You must look at this in conjunction with Network
Processors
> and statistical multiplexing.
>
> A customer need only pay for as much bandwidth as he/she
needs,
> while the remainder can be used for TDM channels.
>
> We believe the case for arbitrary concatenation does
exist:
>
> 1. scales better with technology.
> 2. no massive buffering requirements. (note that virtual
concatenation
> does not "guarantee" hit-less operation. with
buffering, one can limit
> the hit that's all).
> 3. augments native contiguous concatenation. i.e.
contiguous concatenation
> becomes a degenerate case of arbitrary concatenation.
> 4. A customer explicity asked for it. :)
>
> I think there is merit to an effort at interoperability.
>
> -anup
>
> > -----Original Message-----
> > From: Mark.Jones@mail.sprint.com
[mailto:Mark.Jones@mail.sprint.com]
> > Sent: Tuesday, May 15, 2001 12:36 PM
> > To: chickoo66@yahoo.com
> > Cc: GregB@ciena.com; ip-optical@lists.bell-labs.com;
> > mvissers@lucent.com
> > Subject: RE: [IP-Optical] concatenation extensions in
sonet/sdh
> >
> >
> > From my perspective, all necessary applications can be
met by
> > contiguous
> > and virtual concatenation. Adding arbitrary
concatenation simply
> > increases the number of spares to maintain, the number
of
> > attributes to
> > test for interoperability, and the potential complexity
to
> > port cards.
> > The improved bandwidth efficiency you are going to claim
> > won't outweigh
> > the problems I see as a result. Unless you can show a
significant
> > business driver for this, I would recommend not wasting
your
> > time trying
> > to standardize it. The trend is to maintain variable
size
> > connections
> > using packets anyway. Why are we talking about doing
this
> > with TDM? I
> > find it most interesting that this IETF group is
discussing variable
> > size TDM pipes, when routers typically can fill a TDM
pipe at
> > the line
> > rate.
> >
> > Mark Loyd Jones
> > Sprint
> > Technology Planning & Integration
> > 913-534-5247
> > mark.jones@mail.sprint.com
> >
> >
> > > -----Original Message-----
> > > From: chickoo66 [mailto:chickoo66@yahoo.com]
> > > Sent: Tuesday, May 15, 2001 1:47 PM
> > > To: GregB; mvissers; ip-optical
> > > Cc: chickoo66
> > > Subject: RE: [IP-Optical] concatenation extensions in
sonet/sdh
> > >
> > >
> > > I could not agree more.
> > > Arb-Concatenation, being a logical (and graceful)
> > > extension of standard contiguous concatenation,
> > > can easily co-exist with virtual.
> > > Imagine channels such as 2c,5c,6c,7c... 767c :)
> > > However, we need to be able to interoperate
> > > with outside-vendor equipments, with regards
> > > to the multiplexing scheme.
> > > Dr.Berstein/other, do you know of any such
> > > interoperating effort on-going?
> > > Would any one be interested in interoperability
> > > issues pertaining to arb-concat?
> > > I emphasize: arb-conc is complementary to virt-concat.
> > > Comments?
> > > Sanjay
> > >
> > >
> > >
> > > --- "Bernstein, Greg" <GregB@ciena.com> wrote:
> > > > Folks, please note that Arbitrary concatenation is
> > > > not in any of the ITU or
> > > > ANSI standards as Maarten points out below.
> > > > Maarten my understanding is that GFP can be used
> > > > with either standard
> > > > contiguous concatenation or virtual concatenation.
> > > >
> > > > For those interested in arbitrary concatenation for
> > > > the standard sizes,
> > > > e.g., STS-3c, STS-12c, one can just use the payload
> > > > mappings from standard
> > > > contiguous concatenation. A network supporting
> > > > arbitrary concatenation can
> > > > transport these efficiently with no re-grooming.
> > > >
> > > > Note that I think SDH/SONET networks can make use of
> > > > both virtual and
> > > > arbitrary concatenation.
> > > > Greg B.
> > > >
> > > > Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > > > New phone: (510) 573-2237
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Maarten Vissers
[mailto:mvissers@lucent.com]
> > > > Sent: Tuesday, May 15, 2001 1:06 AM
> > > > To: Bernstein, Greg; 'ashritha
thirumalai';
> > > > ip-optical@lists.bell-labs.com
> > > > Subject: Re: [IP-Optical]
concatenation
> > > extensions
> > > > in
> > > > sonet/sdh
> > > >
> > > > << File: Card for Maarten Vissers >>
Greg,
> > > >
> > > > The transport of ethernet signals via
SDH/SONET
> > > > networks is
> > > > being
> > > > defined in T1 and ITU-T to use virtual
> > > > concatenation and GFP
> > > > for
> > > > encapsulation, not arbitrary
concatenation.
> > > >
> > > > The transport of SAN signals (ESCON, FC,
FICON)
> > > > via
> > > > SDH/SONET networks
> > > > is being defined in T1 and ITU-T to use
virtual
> > > > concatenation and GFP
> > > > for encapsulation, not arbitrary
concatenation.
> > > >
> > > > The transport of ATM signals via SDH/SONET
> > > > networks is
> > > > defined in T1 and
> > > > ITU-T to use VC-3/STS-1, VC-4/STS-3c,
> > > > VC-4-4c/STS-12c,
> > > > VC-4-16c/STS-48c,
> > > > VC-4-64c/STS-192c, VC-4-256c/STS-768c and
> > > > STS-1-Xv,
> > > > VC-4-Xv/STS-3c-Xv.
> > > >
> > > > For the case interworking between
subnetworks of
> > > > different
> > > > vendors and
> > > > networks of different operators is
required, the
> > > > above
> > > > signals and
> > > > mappings are to be used.
> > > >
> > > > For the case interworking is not required,
any
> > > > proprietary
> > > > implementation (e.g. arbitrary
concatenation) can
> > > > be used.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > >
> > > > Maarten Vissers wrote:
> > > > >
> > > > > Greg, Sanjay,
> > > > >
> > > > > In additon to Juergen's comment, I would
like to
> > > > point out
> > > > that VC-4-2c,
> > > > > VC-4-3c, VC-4-5c, etc are not longer
part of the
> > > > SDH
> > > > hierarchy (G.707
> > > > > 10/2000), and I doubt if the ITU-T
community
> > > > would like to
> > > > re-introduce
> > > > > these signal types given all the hassle
the
> > > > introduction
> > > > of VC-4-4c
> > > > > (with ATM payload) did cause in the
past.
> > > > >
> > > > > And as Juergen indicated, real arbitrary
> > > > concatenation
> > > > would require the
> > > > > mapping of a VC-4-Xc signal in any set
of X AU-4
> > > > timeslots. As long as
> > > > > you need still a series of contiguous
timeslots
> > > > (i.e.
> > > > arbitrary
> > > > > contiguous concatenation), bandwidth
> > > > defragmenation (or
> > > > re-grooming) is
> > > > > required once every ...
> > > > >
> > > > > I.e. arbitrary contiguous concatenation
(ACC)
> > > > > - still has the same fragmentation issue
that is
> > > > also
> > > > present in today's
> > > > > contiguous concatenation; it is less
restrictive
> > > > from a
> > > > theoretical
> > > > > perspective, but Murphy's law will be
> > > > applicable, and the
> > > > fragmentation
> > > > > will be such that there is no contiguous
set of
> > > > AU4
> > > > timeslots free
> > > > > normally - i.e. from the distance, there
is no
> > > > benifit at
> > > > all from the
> > > > > operational perspective, perhaps even
only a
> > > > disadvantage
> > > > (more complex
> > > > > provisioning due to more flexibility)
> > > > > - ACC signals can not be routed via most
> > > > SDH/SONET
> > > > networks.
> > > > >
> > > > > Within the OTN definition work ongoing,
the ODUk
> > > > multiplexing is
> > > > > intended to be specified with true
arbitrary
> > > > concatenation. Refer to
> > > > > SP15 of the G.709 living list for the
moment.
> > > > Later this
> > > > week a first
> > > > > ODUk multiplexing text proposal will be
issued
> > > > towards
> > > > ITU-T Q.11/15.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Maarten
> > > > >
> > > > > Heiles Juergen wrote:
> > > > > >
> > > > > > Greg, Sanjay,
> > > > > >
> > > > > > if you build up a new network, if you
don't
> > > > have to care
> > > > about an installed base and if you further can
> > > > accept to be restricted to a
> > > > single vendor (E.g. signle ring network) arbitary
> > > > concatenation could be
> > > > fine.
> > > > > > Concerning the upgrade, virtual
concatenation
> > > > would
> > > > often require only a new tributary interface card
> > > > (depending on your system
> > > > design), not an upgrade of the whole network
> > > > element. As you have to install
> > > > this new interface card due to the new service (e.g.
> > > > 100M/1G Ethernet)in any
> > > > case it is not an additional investment.
> > > > > > Greg you mentioned re-grooming as far
as I
> > > > understand
> > > > arbitary (contiguous) concatenation you still need X
> > > > contiguous VCs/SPEs.
> > > > Only the number X and the starting time slot has no
> > > > limitations as it is the
> > > > case for standard contiguous cocnatenation. So you
> > > > still ahve to do
> > > > re-grooming if for example time slots 1, 5 and 6 are
> > > > available in an STM-16
> > > > signal as these time slots are not contgiguous.
> > > > Arbitary concatenation has
> > > > less restrictions compared to standard contiguous
> > > > concatenation, but still
> > > > has restrictions.
> > > > > > Sanjay, you talked about OC3072. We
might have
> > > > 160
> > > > Gbit/s in the future in some parts of the network,
> > > > but others are still
> > > > running with lower line speeds (e.g. long distance
> > > > systems, trans oceanic
> > > > systems) as the higher bit rate imposes limitations
> > > > in the distance and you
> > > > have an isntalled base. With virtual concatenation
> > > > it is not a problem to
> > > > transport a 160 Gbit/s service (if such a kind of
> > > > service is needed in any
> > > > case) over 4x40G or 16x10G.
> > > > > > Note that arbitary concatenation was
diffcult
> > > > to
> > > > implement with the chip technology available some
> > > > years ago when the
> > > > processing was often done in parallel on several
> > > > chips. Todays single chip
> > > > solutions allowed to introduce arbitary
> > > > concatenation. For the size of the
> > > > alignment buffer for virtual concatenation it is
> > > > also only a question of the
> > > > size of available memory chips which will increase
> > > > over time.
> > > > > > Sanjay you mentioned that it might be
possible
> > > > to use
> > > > just an SW upgrade for an cross-connect in order to
> > > > get arbitary
> > > > concatenation support. I don't think so as arbitary
> > > > concateantion requries
> > > > specific pointer processing which is done in HW.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Juergen
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Bernstein, Greg
[SMTP:GregB@ciena.com]
> > > > > > > Sent: Monday, May 14, 2001 5:55 AM
> > > > > > > To: 'ashritha thirumalai'; Fong,
Man Wing;
> > > > Maarten
> > > > Vissers; Heiles Juergen
> > > > > > > Cc: ip-optical@lists.bell-labs.com
> > > > > > > Subject: RE: [IP-Optical]
concatenation
> > > > extensions in sonet/sdh
> > > > > > >
> > > > > > > Hi Sanjay see comments in line
below.
> > > > > > > Greg B.
> > > > > > >
> > > > > > > Dr. Greg M. Bernstein, Senior
> > > > Scientist, Ciena
> > > > > > > New phone: (510) 573-2237
> > > > > > >
> > > > > > >
> > > > > > > -----Original
Message-----
> > > > > > > From: ashritha
thirumalai
> > > > [mailto:chickoo66@yahoo.com]
> > > > > > > Sent: Saturday, May
12, 2001
> > > > 9:54 AM
> > > > > > > To: Bernstein,
Greg; Fong,
> > > > Man Wing;
> > > > Maarten Vissers;
> > > > > > > Heiles Juergen
> > > > > > > Cc:
> > > > ip-optical@lists.bell-labs.com
> > > > > > > Subject: RE:
> > > > [IP-Optical]
> > > > concatenation extensions in
> > > > > > > sonet/sdh
> > > > > > >
> > > > > > > Dr. Bernstein,
> > > > > > >
> > > > > > > Glad you replied.
> > > > > > >
> > > > > > > A few further
questions:
> > > > > > >
> > > > > > > 1. how are two
different
> > > > vendors
> > > > implementing arb-conc
> > > > > > > going to
inter-operate? (i.e.
> > > > how are
> > > > bytes in
> > > > > > > an arb-concatenated
channel
> > > > multiplexed
> > > > into the
> > > > > > > rest of Sonet/SDH
timeslots?)
> > > > > > > > For non-standard
sizes this
> > > > needs some
> > > > work. I'm happy to
> > > > > > > work anyone in this area. Starting
with the
> > > > standard
> > > > sizes isn't a problem
> > > > > > > we just use the already standardized
> > > > mappings.
> > > > > > > 2. would you be able
to list
> > > > some
> > > > vendors that
> > > > > > > do (or claim to)
support
> > > > arb-concat?
> > > > > > > > Ciena's CoreDirector
for
> > > > one. I know
> > > > of other vendors but
> > > > > > > I'm not sure if they've publicly
announced.
> > > > > > > 3. and a repeat
question. why
> > > > should one
> > > > go with
> > > > > > > arb-concat when
virt-cont
> > > > (kludgy as it
> > > > may be)
> > > > > > > has been standardized.
(in my
> > > > limited
> > > > understanding
> > > > > > > of virt-conc, it does
avoid
> > > > the
> > > > "re-grooming" that
> > > > > > > you alluded to).
> > > > > > > > Well virtual
concatenation
> > > > can do
> > > > everything but it>
> > > > > > > requires the edge equipment to be
upgraded.
> > > > If folks
> > > > want to preserve their
> > > > > > > investments around the edge and
> > > > incrementally upgrade
> > > > the core then any line
> > > > > > > connecting two pieces of equipment
> > > > supporting
> > > > arbitrary concatenation
> > > > > > > doesn't need to be re-groomed or be
used
> > > > inefficiently. Hence it's a good
> > > > > > > feature for core equipment, but
maybe not so
> > > > hot
> > > > compared to virtual
> > > > > > > concatenation at the edge.
> > > > > > >
> > > > > > > greatly appreciate a
reply.
> > > > > > >
> > > > > > > Thanx,
> > > > > > > Sanjay.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --- "Bernstein, Greg"
> > > > <GregB@ciena.com>
> > > > wrote:
> > > > > > > > Hi sorry to be out
of the
> > > > loop for a
> > > > while. Man
> > > > > > > > Wing's assesment and
the
> > > > > > > > concerns about
upgrades are
> > > > fairly
> > > > correct except:
> > > > > > > > (1) With the new
generation
> > > > of
> > > > SONET/SDH cross
> > > > > > > > connects arbitrary
is a
> > > > > > > > feature. I can
think of at
> > > > least one
> > > > new and very
> > > > > > > > popular switch that
has
> > > > > > > > this feature.
> > > > > > > > (2) I also know of
access
> > > > equipment
> > > > vendors that
> > > > > > > > offer this feature
(but not
> > > > > > > > virtual
concatenation).
> > > > > > > > (3) There is a bit
more
> > > > fundamental
> > > > reason behind
> > > > > > > > the usefulness of
> > > > > > > > arbitrary
concatenation.
> > > > Avoiding the
> > > > need to
> > > > > > > > "re-groom" the
circuits on a
> > > > > > > > line (the nasty
service
> > > > impacting
> > > > process of
> > > > > > > > remapping circuits
to time
> > > > > > > > slots so that you
can add a
> > > > new
> > > > concatenated circuit
> > > > > > > > within the standard
> > > > > > > > contiguous
concatenation
> > > > constraints).
> > > > > > > > As to how it got
into the
> > > > ODSI
> > > > specification, the
> > > > > > > > answer is fairly
simple,
> > > > > > > > folks (including
myself)
> > > > asked for it
> > > > to be
> > > > > > > > included, just like
in the
> > > > GMPLS
> > > > > > > > specification. I
haven't
> > > > found a
> > > > customer out there
> > > > > > > > that likes to
re-groom
> > > > > > > > traffic (or the
bandwidth
> > > > inefficiency
> > > > from not
> > > > > > > > regrooming).
> > > > > > > >
> > > > > > > > Greg B.
> > > > > > > >
> > > > ***********************************
> > > > > > > > Dr. Greg M.
Bernstein
> > > > > > > > Senior Scientist,
Ciena
> > > > Corporation
> > > > > > > >
> > > > > > > > -----Original
Message-----
> > > > > > > > From: ashritha
thirumalai
> > > > > > > >
[mailto:chickoo66@yahoo.com]
> > > > > > > > Sent: Friday, May
11, 2001
> > > > 1:50 PM
> > > > > > > > To: Fong, Man Wing;
Maarten
> > > > Vissers;
> > > > Heiles Juergen
> > > > > > > > Cc:
> > > > ip-optical@lists.bell-labs.com
> > > > > > > > Subject: RE:
[IP-Optical]
> > > > concatenation extensions
> > > > > > > > in sonet/sdh
> > > > > > > >
> > > > > > > >
> > > > > > > > Well, arb-conct is
most
> > > > really useful
> > > > for data
> > > > > > > > (i.e.
Packet-Over-Sonet).
> > > > i.e. one can
> > > > provide
> > > > > > > > an STS19c or so for
a 1GbE
> > > > pipe (as
> > > > opposed to
> > > > > > > > an STS48c as is
currently
> > > > being done).
> > > > This
> > > > > > > > goal is same as that
of
> > > > virt-conc.
> > > > > > > >
> > > > > > > > I am not really sure
how an
> > > > interconnection will
> > > > > > > > be problematic with
a DACS?
> > > > Could you
> > > > elaborate
> > > > > > > > kindly?
> > > > > > > >
> > > > > > > > Thanx,
> > > > > > > > Sanjay
> > > > > > > > --- "Fong, Man Wing"
> > > > <MFong@WhiteRockNetworks.com>
> > > > > > > > wrote:
> > > > > > > > > Hi Sanjay,
> > > > > > > > >
> > > > > > > > > Here is my 2 cents
worth
> > > > of
> > > > comments.
> > > > > > > > >
> > > > > > > > > 3. arb. conc. as
well as
> > > > virt. conc.
> > > > require
> > > > > > > > > upgrades
> > > > > > > > > at the end
points,
> > > > since all
> > > > systems in a ring
> > > > > > > > > will be of the
same
> > > > vendor
> > > > anyway. (i.e. if one
> > > > > > > > > system supports
arb.
> > > > conc. so
> > > > will the rest in
> > > > > > > > > the ring).
> > > > > > > > > Not quiet true.
There
> > > > might be a
> > > > problem when
> > > > > > > > > interconnecting
with a
> > > > cross
> > > > > > > > > connect system.
For my
> > > > understanding, I can't
> > > > > > > > think
> > > > > > > > > of any cross
connect
> > > > > > > > > system support
arbitrary
> > > > concatenation.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Man Wing
> > > > > > > > >
> > > > > > > > > -----Original
Message-----
> > > > > > > > > From:
ashritha
> > > > thirumalai
> > > > > > > > >
> > > > [mailto:chickoo66@yahoo.com]
> > > > > > > > > Sent:
Friday, May
> > > > 11, 2001
> > > > 11:55 AM
> > > > > > > > > To: Maarten
Vissers;
> > > > Heiles Juergen
> > > > > > > > > Cc: 'ashritha
thirumalai';
> > > > > > > > >
> > > > ip-optical@lists.bell-labs.com
> > > > > > > > > Subject: Re:
> > > > [IP-Optical]
> > > > concatenation extensions
> > > > > > > > > in sonet/sdh
> > > > > > > > >
> > > > > > > > > Thanks Juergen and
Maarten
> > > > for you
> > > > valuable
> > > > > > > > > feedback.
> > > > > > > > >
> > > > > > > > > Here's my dilemma:
> > > > > > > > >
> > > > > > > > > 1. arb.
concatenation is a
> > > > natural
> > > > and elegant
> > > > > > > > > extension to
sonet/sdh
> > > > contigous-concatenation.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2. arb.
concatenation
> > > > scales very
> > > > well with rate. >
> > > > > > > > > imagine the
buffering
> > > > required
> > > > for OC768 or i
> > > > > > > > > dare say,
OC3072 in a
> > > > framer
> > > > device supporting
> > > > > > > > > virtual
concatenation.
> > > > (while an
> > > > ANSI draft
> > > > > > > > > recommends a
minimum of
> > > > 1 frame's
> > > > worth of
> > > > > > > > > buffering, this
is
> > > > hardly
> > > > sufficient. most
> > > > > > > > people
> > > > > > > > > want about 16
frames
> > > > worth of
> > > > buffering).
> > > > > > > > >
> > > > > > > > > 3. in a given
ring, it is
> > > > virtually
> > > > unknown to
> > > > > > > > > intermix
systems from
> > > > two
> > > > vendors.
> > > > > > > > > therefore, a
system
> > > > (say and ADM)
> > > > supporting
> > > > > > > > > arb.
concatenation can
> > > > gracefully
> > > > co-exist with
> > > > > > > > > its sibling
systems on
> > > > the same
> > > > ring.
> > > > > > > > >
> > > > > > > > > 4. now the
question is
> > > > what happens
> > > > at end-points.
> > > > > > > >
> > > > > > > > > well, the
end-points
> > > > (especially
> > > > the receive)
> > > > > > > > > will have to
support
> > > > arb
> > > > concatenation.
> > > > > > > > > (if there is a
cross
> > > > connect, it
> > > > > > > > > could possibly
be
> > > > handled by
> > > > software alone).
> > > > > > > > >
> > > > > > > > > On the other
hand,
> > > > virtual
> > > > concatenation will
> > > > > > > > > need support as
well at
> > > > the
> > > > end-points. i.e.
> > > > > > > > > current systems
will
> > > > need to be
> > > > upgraded.
> > > > > > > > >
> > > > > > > > > my summary (i hope
you
> > > > will critique
> > > > this):
> > > > > > > > >
> > > > > > > > > 1. arb. conc. is a
more
> > > > elegant
> > > > solution.
> > > > > > > > > 2. arb. conc.
scales quite
> > > > well with
> > > > rate, while
> > > > > > > > > vir. conc. gets
uglier
> > > > and uglier
> > > > to implement.
> > > > > > > >
> > > > > > > > > 3. arb. conc. as
well as
> > > > virt. conc.
> > > > require
> > > > > > > > > upgrades
> > > > > > > > > at the end
points,
> > > > since all
> > > > systems in a ring
> > > > > > > > > will be of the
same
> > > > vendor
> > > > anyway. (i.e. if one
> > > > > > > > > system supports
arb.
> > > > conc. so
> > > > will the rest in
> > > > > > > > > the ring).
> > > > > > > > > 4. why is ODSI
making a
> > > > mention of
> > > > arb.
> > > > > > > > > concatenation
> > > > > > > > > in their
functional
> > > > spec?
> > > > > > > > >
> > > > > > > > > Thanx,
> > > > > > > > > Sanjay.
> > > > > > > > > --- Maarten
Vissers
> > > > <mvissers@lucent.com> wrote:
> > > > > > > > > > Sanjay,
> > > > > > > > > >
> > > > > > > > > > Arbitrary
concatenation
> > > > was
> > > > present in the very
> > > > > > > > > > first versions
of T.105
> > > > > > > > > > and G.707
(called G.709
> > > > at the
> > > > time). It was
> > > > > > > > never
> > > > > > > > > > implemented,
until
> > > > > > > > > > ATM people
decided
> > > > (without
> > > > consultation with
> > > > > > > > > > transport
people) to
> > > > > > > > > > define ATM over
> > > > VC-4-4c/STS-12c.
> > > > The problems
> > > > > > > > this
> > > > > > > > > > has caused
initially
> > > > > > > > > > in the networks
was
> > > > tremendous;
> > > > VC-4-4c/STS-12c
> > > > > > > > > > couldn't be
transported
> > > > > > > > > > as a tributary
signal in
> > > > e.g.
> > > > STM-16/OC-48
> > > > > > > > > signals,
> > > > > > > > > > it could only be
> > > > > > > > > > transported
within an
> > > > STM-4/OC-12
> > > > directly on
> > > > > > > > > fiber
> > > > > > > > > > (very
expensive!!).
> > > > > > > > > > Only when new
network
> > > > elements
> > > > where installed
> > > > > > > > > > supporting
> > > > > > > > > > VC-4-4c/STS-12c
this
> > > > ATM-service
> > > > could be
> > > > > > > > handled
> > > > > > > > > by
> > > > > > > > > > the transport
> > > > > > > > > > networks at
normal
> > > > costs. To
> > > > transport
> > > > > > > > > > VC-4-4c/STS-12c
over the
> > > > original
> > > > > > > > > > SDH networks,
> > > > contiguous/virtual
> > > > concatenation
> > > > > > > > > > conversion
function has
> > > > > > > > > > been defined
(see
> > > > G.707); special
> > > > cont/virt conc
> > > > > > > > > > conversion
interface
> > > > > > > > > > port units have
been
> > > > designed and
> > > > installed.
> > > > > > > > > >
> > > > > > > > > > Arbitrary
concatenation
> > > > has been
> > > > taken out in
> > > > > > > > the
> > > > > > > > > > latest versions
of the
> > > > > > > > > > two standards
for the
> > > > reasons
> > > > mentioned by
> > > > > > > > Juergen
> > > > > > > > > > and indicated
above.
> > > > > > > > > > I would say that
most
> > > > likely 99%
> > > > of the existing
> > > > > > > > > > SONET/SDH
networks do
> > > > > > > > > > not support
arbitrary
> > > > concatenation, and there
> > > > > > > > are
> > > > > > > > > > no client
signals
> > > > > > > > > > defined that are
mapped
> > > > into
> > > > arbitrary
> > > > > > > > > concatenated
> > > > > > > > > > signals. So I
would
> > > > > > > > > > assume that
arbitrary
> > > > concatenation is a dead
> > > > > > > > > body,
> > > > > > > > > > not worth to
invest
> > > > > > > > > > a single penny
in.
> > > > Virtual
> > > > concatenation is the
> > > > > > > > > > future.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Maarten
> > > > > > > > > >
> > > > > > > > > > Heiles Juergen
wrote:
> > > > > > > > > > >
> > > > > > > > > > > Sanjay,
> > > > > > > > > > >
> > > > > > > > > > > arbitary
contiguous
> > > > concatenation has to be
> > > > > > > > > > supported by all
network
> > > > elements
> > > > along the>
> > > > > > > > path,>
> > > > > > > > > > while virtual
> > > > concatenation needs
> > > > only support
> > > > > > > > at
> > > > > > > > > > the end systems
> > > > terminating
> > > > virtual
> > > > > > > > concatenation
> > > > > > > > > > and providing
access to
> > > > the client
> > > > signal.
> > > > > > > > > > > Arbitary
contiguous
> > > > concatenation is not
> > > > > > > > > > standardized and
support
> > > > only by
> > > > several
> > > > > > > > vendors.
> > > > > > > > > > Exisitng
networks don't
> > > > support
> > > > it. It would
> > > > > > > > > require
> > > > > > > > > > a replacement of
most
> > > > network
> > > > elements,
> > > > > > > > something
> > > > > > > > > > operators don't
want.
> > > > With virtual
> > > > concatenation
> > > > > > > > > you
> > > > > > > > > > can go through
exisitng
> > > > networks.
> > > > Only the end
> > > > > > > > > > systems that
support the
> > > > specific
> > > > client signal
> > > > > > > > > have
> > > > > > > > > > to support
virtual
> > > > concatenation
> > > > also.
> > > > > > > > > > > Furthermore
virtual
> > > > concatenation allows to
> > > > > > > > > > disribute the
individual
> > > > VCs/STS-SPEs over
> > > > > > > > several
> > > > > > > > > > STM/OC signals,
which is
> > > > not
> > > > possible with
> > > > > > > > > > contiguous
> > > > concatenation. An
> > > > application for
> > > > > > > > this
> > > > > > > > > is
> > > > > > > > > > the transport of
a 10
> > > > Gbit/s
> > > > paylaod over
> > > > > > > > 4xOC-48
> > > > > > > > > in
> > > > > > > > > > a OC-48 based
WDM
> > > > system.
> > > > > > > > > > > The LCAS (Link
> > > > Capacity
> > > > Adjustment Scheme)
> > > > > > > > > allows
> > > > > > > > > > to modify the
number of
> > > > virtual
> > > > concatenated
> > > > > > > > > signals
> > > > > > > > > > (and as such the
> > > > transport
> > > > bandwidth) on the
> > > > > > > > fly.
> > > > > > > > > > > In my view
virtual
> > > > concatenation
> > > > has a longer
> > > > > > > > > > lifetime.
> > > > > > > > > > >
> > > > > > > > > > > Regards
> > > > > > > > > > >
> > > > > > > > > > > Juergen
> > > > > > > > > > >
> > > > > > > > > > > >
-----Original
> > > > Message-----
> > > > > > > > > > > > From:
ashritha
> > > > thirumalai
> > > > > > > > > >
> > > > [SMTP:chickoo66@yahoo.com]
> > > > > > > > > > > > Sent:
Monday, May
> > > > 07, 2001
> > > > 9:05 PM
> > > > > > > > > > > > To:
> > > > ip-optical@lists.bell-labs.com
> > > > > > > > > > > > Cc:
> > > > chickoo66@yahoo.com
> > > > > > > > > > > > Subject:
> > > > [IP-Optical]
> > > > concatenation
> > > > > > > > > > extensions in
sonet/sdh
> > > > > > > > > > > >
> > > > > > > > > > > > All,
> > > > > > > > > > > >
> > > > > > > > > > > > A newbie
question.
> > > > (and a
> > > > digression from
> > > > > > > > > > current
> > > > > > > > > > > > threads)
> > > > > > > > > > > >
> > > > > > > > > > > > Virtual
> > > > concatenation seems to
> > > > have been
> > > > > > > > > > accepted
> > > > > > > > > > > > as standard
> > > > procedure.
> > > > Lucent/Agere, Cypress
> > > > > > > > > etc
> > > > > > > > > > > > seem to have
sonet
> > > > framers
> > > > that support
> > > > > > > > > virtual
> > > > > > > > > > > >
concatenation.
> > > > > > > > > > > >
> > > > > > > > > > > > However,
there has
> > > > been some
> > > > discussion on
> > > > > > > > > > > > arbitrary
> > > > concatenation as
> > > > well. arbitrary
> > > > > > > > > > > >
concatenation seems
> > > > to be a
> > > > graceful
> > > > > > > > extension
> > > > > > > > > > > > of
sonet/sdh's
> > > > contiguous
> > > > concatenation,
> > > > > > > > while
> > > > > > > > > > > > virtual
> > > > concatenation seems
> > > > like such a
> > > > > > > > hack.
> > > > > > > > > > > >
> > > > > > > > > > > > I invite
your
> > > > opinions and
> > > > comments on the
> > > > > > > > > > > >
applications,
> > > > relevance and
> > > > potential
> > > > > > > > > lifetimes
> > > > > > > > > > > > of virtual
and
> > > > arbitrary
> > > > concatenation
> > > > > > > > > schemes.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanx,
> > > > > > > > > > > > Sanjay.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > __________________________________________________
> > > > > > > > > > > > Do You
Yahoo!?
> > > > > > > > > > > > Yahoo!
Auctions -
> > > > buy the
> > > > things you want at
> > > > > > > > > > great prices
> > > > > > > > > > > >
> > > > http://auctions.yahoo.com/
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > _______________________________________________
> > > > > > > > > > > > IP-Optical
mailing
> > > > list
> > > > > > > > > > > >
> > > > IP-Optical@lists.bell-labs.com
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > _______________________________________________
> > > > > > > > > > > IP-Optical
mailing
> > > > list
> > > > > > > > > > >
> > > > IP-Optical@lists.bell-labs.com
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > >
http://lists.bell-labs.com/mailman/listinfo/ip-optical>
> > > > > > > > > begin:vcard
> > > > > > > > > >
n:Vissers;Maarten
> > > > > > > > > > tel;cell:+31 62
061 3945
> > > > > > > > > > tel;fax:+31 35
687 5976
> > > > > > > > > > tel;home:+31 35
526 5463
> > > > > > > > > > tel;work:+31 35
687 4270
> > > > > > > > > >
x-mozilla-html:FALSE
> > > > > > > > > > org:Lucent
Technologies
> > > > Nederland;NA&CPSE
> > > > > > > > > > version:2.1
> > > > > > > > > >
> > > > email;internet:mvissers@lucent.com
> > > > > > > > > >
> > > > adr;quoted-printable:;;Botterstraat
> > > > > > > > > >
45=0D=0A=0D=0A;1271 XL
> > > > Huizen;;;The Netherlands>
> > > > > > > > >> > > fn:Maarten
Vissers
> > > > > > > > > > end:vcard
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > __________________________________________________
> > > > > > > > > Do You Yahoo!?
> > > > > > > > > Yahoo! Auctions -
buy the
> > > > things you
> > > > want at great
> > > > > > > > > prices
> > > > > > > > >
http://auctions.yahoo.com/
> > > > > > > > >
> > > > > > > > >
> > > > _______________________________________________
> > > > > > > > > IP-Optical mailing
list
> > > > > > > > >
> > > > IP-Optical@lists.bell-labs.com
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > __________________________________________________
> > > > > > > > Do You Yahoo!?
> > > > > > > > Yahoo! Auctions -
buy the
> > > > things you
> > > > want at great
> > > > > > > > prices
> > > > > > > >
http://auctions.yahoo.com/
> > > > > > > >
> > > > > > > >
> > > > _______________________________________________
> > > > > > > > IP-Optical mailing
list
> > > > > > > >
> > > > IP-Optical@lists.bell-labs.com
> > > > > > > >
> > > > > > >
> > > >
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > > >
> > > > > > >
> > > > > > >
> > > > __________________________________________________
> > > > > > > Do You Yahoo!?
> > > > > > > Yahoo! Auctions - buy
the
> > > > things you
> > > > want at great prices
> > > > > > >
http://auctions.yahoo.com/
> > > > > >
> > > > > >
> > > > _______________________________________________
> > > > > > IP-Optical mailing list
> > > > > > IP-Optical@lists.bell-labs.com
> > > > > >
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Auctions - buy the things you want at great
prices
> > > http://auctions.yahoo.com/
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > IP-Optical@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> >
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical