[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
- To: Michael Waldo <mwwaldo@flash.net>
- Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
- From: Maarten Vissers <mvissers@lucent.com>
- Date: Thu, 17 May 2001 13:26:10 +0200
- Cc: "Bernstein, Greg" <GregB@ciena.com>, "'Mannie, Eric'" <Eric.Mannie@ebone.com>, ccamp@ops.ietf.org, mpls@UU.NET
- Delivery-date: Thu, 17 May 2001 04:28:43 -0700
- Envelope-to: ccamp-data@psg.com
- Organization: Lucent Technologies
- Original-CC: "Bernstein, Greg" <GregB@ciena.com>, "'Mannie, Eric'" <Eric.Mannie@ebone.com>, ccamp@ops.ietf.org, mpls@UU.NET
Waldo,
I am copying an email conversation ongoing in the IP-optical mailing
list on arbitrary concatenation. Hope this provides the input you are
looking for.
Bottom line is that neither arbitrary contiguous concatenation nor
arbitrary concatenation is part of the SONET/SDH standards. It is a
vendor proprietary extension of these SONET/SDH standards, for which it
is in my (and some other peoples) view highly unlikely that it will be
included in the SONET/SDH standards.
As you indicate with virtual concatenation being the international
standard and the direction in the industry today, arbitrary
concatenation doesn't add anything to the transport network; contrary,
it would cause interworking problems.
But arbitrary contiguous concatenation wouldn't add anything either, and
compared to arbitrary concatenation it would still have the bandwidth
fragmentation problem that standard contiguous concatenation is having.
I.e. arbitrary contiguous concatenation is worse.
All,
The GMPLS SONET/SDH extension document is thus defining a control plane
which supports capabilities in the transport plane that are not
supported by the international standards for this transport plane.
Personally, I find this very incorrect. IETF has no mandate to change
the SONET/SDH standards. A control plane for the transport network
should follow the transport network standards, not define its own
transport network.
Regards,
Maarten
---------------
Maarten Vissers wrote:
>
> 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
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:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard