[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Dear Maarten et all,
For "arbitrary contiguous concatenation" you stated (and of course)
i agree it has been removed but the question is: what about existing
equipments it is not because it has been removed from recommendation
that products disappear - can someone confirm the use of arbitrary
contiguous concatenation ? - there is also a difference between "what
the ideal situation should be and what the situation is today in
SDH/Sonet networks"
=> ... so i don't really think it is a big issue and the following
alternative can be used to determine what can be done:
- either we strictly comply to "last versions" of G.707 / T1.105
in that case "arbitrary contiguous concatenation" must be removed
- or we do not strictly comply today then the "arbitrary concatenation"
has to be considered in addition to "arbitrary contiguous
concatenation" - in that case a submission to the ITU-T/T1 should be
ideally proposed in order to "harmonize" the specifications
- or we stay as defined today making the assumption that "arbitrary
contiguous concatenation" was included so that some equipments might
still support it.
Any other possibility ?
Regards,
Dimitri.
Maarten Vissers wrote:
>
> 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:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard