[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Hi,
I think there will always be some set of vendors in the industry that
will add proprietary extensions to standards-based specifications
regardless of whether it is transport standards or protocol standards.
The question that should be asked first is: is GMPLS going to add
proprietary extensions above and beyond what is standards specified? If
the answer is "yes", then that sets the precedence for any and all
vendors to request inclusion of their favorite proprietary extensions to
GMPLS.
And if one specific proprietary extension gets an enumerated codepoint,
then that also sets the precedence for any and all vendors to request
specific codepoints for their favorite proprietary extensions.
Are we prepared to accept that?
Zhi
BTW, currently the virtual concatenated capability specified for GMPLS
only allows for co-routing of the individual component VCs, while the
standard calls for any routing (over any links) of the individual
component VCs (more flexible). As such, do we need to call this out
explicitly in the GMPLS draft so that people do not get a
mis-understanding of what virtual concatenation can do?
We can obviously extend this for GMPLS in the future to support the full
flexibility allowed for virtual concatenation.
Dimitri Papadimitriou wrote:
>
> 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
> > > > > > >