Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

From: "Bernstein, Greg" <[email-masked]>
Date: Wed, 16 May 2001 15:05:58 -0700

We started out with the simple term "arbitrary concatenation" a while back
to mean arbitrary in size and in timeslots used.  I'm not sure what was
meant when we added the "contiguous" to this.  Was it:
(1)	Treat this as one big signal within a single SONET Line (SDH MS),
with potentially arbitrary timeslots used.
(2)	Treat this as one big signal within a single SONET line (SDH MS),
with the timeslot numbering lying within a single range, i.e.,  X through Y,
with X < Y.

If (1) then we need a list of time slots. If (2) then only the beginning
time slot is needed.  The problem with (2) is that it is a pretty useless
feature, i.e., doesn't prevent the need for re-grooming and seemed like a
mistake from the rather long gestation period for this specification rather
than something truly intended.

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Mannie, Eric [mailto:[email-masked]]
		Sent:	Wednesday, May 16, 2001 12:44 PM
		To:	Bernstein, Greg; [email-masked]; [email-masked]
		Subject:	RE: Small issue on
draft-ietf-ccamp-gmpls-sdh-00.txt

		Dear All,

		Sorry I was confused, the original text of the draft is
correct:

		With any kind of ***contiguous*** concatenation there is one
big signal, so
		one and only one label (pointer) is needed (otherwise it is
not a contiguous
		concatenation). With any kind of virtual concatenation,
there are several
		VC's, so one label (pointer) per VC is needed. Even if all
the VC's
		virtually concatenated are contiguous (by coincidence) we
still need to
		identify each of them.

		Arbitrary and standard concatenations are orthogonal with
contiguous and
		virtual concatenations.

		Arbitrary means anything that is not standard.

		We use a code to differentiate between standard and
arbitrary contiguous
		concatenation to avoid that a downstream node returns a
timeslot at a
		position not supported by the upstream node. The upstream
node indicates the
		number and types of signals to be concatenated and the
downstream node
		cannot change it (it can just accept or refuse).

		We don't need a code to differentiate between standard
versus arbitrary
		virtual concatenation because there is no restriction anyway
on the timeslot
		positions that can return the downstream node. Again, the
upstream node
		indicates the number and types of signals to be concatenated
and the
		downstream node cannot change that (it can just accept or
refuse). SDH 1996
		restricts the virtual concatenation to some well defined
signals, while SDH
		2000 allows everything that make sense. But for the previous
reasons we
		don't need to differentiate between the two (thing about the
reason why you
		put a signaling element in a signaling message).

		Agreed ?

		Kind regards,

		Eric

		-----Original Message-----
		From: Bernstein, Greg [mailto:[email-masked]]
		Sent: Wednesday, May 16, 2001 5:33 PM
		To: [email-masked]; [email-masked]
		Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

		Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:

		   In case of any type of contiguous concatenation (e.g.
standard or
		   arbitrary concatenation), only one label appears in the
Label
		   field. That label is the lowest signal of the
contiguously
		   concatenated signal. By lowest signal we mean the one
having the
		   lowest label when compared as integer values, i.e. the
first
		   component signal of the concatenated signal encountered
when
		   descending the tree.

		   In case of virtual concatenation, the explicit ordered
list of all
		   labels in the concatenation is given. Each label
indicates a
		   component of the virtually concatenated signal.

		This does not reflect the intent of arbitrary concatenation-
arbitrary, size
		and placement of timeslots.  Otherwise the main benefit of
arbitrary
		concatenation, preventing re-grooming is lost.  Corrected
text could read:

		    In the case of standard contiguous, only one label
appears in the Label
		   field. That label is the lowest signal of the standard
contiguously
		   concatenated signal. By lowest signal we mean the one
having the
		   lowest label when compared as integer values, i.e. the
first
		   component signal of the concatenated signal encountered
when
		   descending the tree.

		   In the cases of arbitrary or virtual concatenation, the
explicit ordered
		list of all
		   labels in the concatenation is given. Each label
indicates a
		   component of the arbitrary or virtually concatenated
signal.

		Greg B.
			Dr. Greg M. Bernstein, Senior Scientist, Ciena 
			New phone: (510) 573-2237

---

From: Michael Waldo <[email-masked]>
Date: Wed, 16 May 2001 17:41:38 -0500

your (1) sounds more like virtual concatenation to me

(2) is what I have considered to be arbitrary concatenation. This could be
useful when compared to standard contiguous concatenation because it could make
more efficient use of the bandwidth within the SONET line (SDH MS) eg, using an
STS-2c when only 100Mbs is needed. Standard contiguous concatenation payload
values being 3c, 12c, 48c, 192c for SONET.

Considering virtual concatenation, arbitrary concatenation doesn't seem to have
as much appeal (pretty useless).

Has the term "arbitrary concatenation" been defined anywhere? I've seen
contiguous and virtual definitions, but I looked through the references in this
draft, (as well as G.707 and T1.105) and I could not find the "arbitrary"
definition.

-Waldo

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Thu, 17 May 2001 00:49:12 +0200

Greg et all,

By taking a look on the version -00 of the draft (published in October
2000 - at that time draft-ietf-mpls-generalized-signalling-00.txt 
includes sonet/sdh extensions) it was clearly mentioned "arbitrary 
contiguous concatenation" in the document !

[...]
Requested Grouping Type (RGT): 4 bits

This field indicates the SDH/SONET type of grouping requested
for the LSP, it is used to constraint the type of concatenation. 
The values are defined in the following table:

Value    Grouping type
-----    ----------------------------------
  0      (Implies no concatenation/bundling when RNC = RT = 0)
  1      Virtual concatenation         
  2      Contiguous standard concatenation             
  3      Contiguous arbitrary concatenation
  4      Inverse Multiplexing
[...]

So either i don't understand what "start out" means or you probably
refer to an older version of the document or...  but clearly the
meaning of "contiguous arbitrary concatenation" has not change since
then.

The reference at that time was the document draft-mack-crane-gmpls-
signaling-enhancements-00.txt - section 6.

[...]
Virtual concatenation requires co-routing and implies a bonding 
function at the endpoints of the group.  For contiguous standard 
concatenation, there must be a standard number of components 
(4, 16, 64, etc. for SDH; 3, 12, 48, etc. for SONET), and they 
must be in one higher order container. For contiguous arbitrary 
concatenation, the number of components is arbitrary (2, 3, 4, à) 
and they still must be routed in one higher order container.
[...]

However in your draft draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      
(published in November 2000), you mention the term "flexible" or 
"arbitrary concatenation" in section 6.1.2:

[...]
Due to these disadvantages some SONET framer manufacturers now
support "flexible"  or  arbitrary concatenation, i.e., no restrictions
on the size of an STS-Mc (as long as M <= N) and no constraints on the
STS-1 timeslots used to convey it, i.e., the signals can use any 
combination of available time slots.
[...]

So, it does not surprise me that this discrepancy occurs... since
we speak about different types of concatenation and "arbitrary 
concatenation" is a third type of concatenation (in addition to 
contiguous and virtual concatenation defined in ITU-T/T1 standards) 

Regards,
Dimitri.

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 17 May 2001 13:26:10 +0200

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
> >
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, May 15, 2001 12:36 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > 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
> > > [email-masked]
> > >
> > >
> > > > From: chickoo66 [mailto:[email-masked]]
> > > > 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" <[email-masked]> 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.
> > > > >
> > > > >           From:   Maarten Vissers [mailto:[email-masked]]
> > > > >           Sent:   Tuesday, May 15, 2001 1:06 AM
> > > > >           To:     Bernstein, Greg; 'ashritha thirumalai';
> > > > > [email-masked]
> > > > >           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
> > > > >           > >
> > > > >           > > > From: Bernstein, Greg [SMTP:[email-masked]]
> > > > >           > > > Sent: Monday, May 14, 2001 5:55 AM
> > > > >           > > > To:   'ashritha thirumalai'; Fong, Man Wing;
> > > > > Maarten
> > > > > Vissers; Heiles Juergen
> > > > >           > > > Cc:   [email-masked]
> > > > >           > > > Subject:      RE: [IP-Optical] concatenation
> > > > > extensions in sonet/sdh
> > > > >           > > >
> > > > >           > > > Hi Sanjay see comments in line below.
> > > > >           > > > Greg B.
> > > > >           > > >
> > > > >           > > >               From:   ashritha thirumalai
> > > > > [mailto:[email-masked]]
> > > > >           > > >               Sent:   Saturday, May 12, 2001
> > > > > 9:54 AM
> > > > >           > > >               To:     Bernstein, Greg; Fong,
> > > > > Man Wing;
> > > > > Maarten Vissers;
> > > > >           > > > Heiles Juergen
> > > > >           > > >               Cc:
> > > > > [email-masked]
> > > > >           > > >               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"
> > > > > <[email-masked]>
> > > > > 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
> > > > >           > > >               >
> > > > >           > > >               > From: ashritha thirumalai
> > > > >           > > >               > [mailto:[email-masked]]
> > > > >           > > >               > Sent: Friday, May 11, 2001
> > > > > 1:50 PM
> > > > >           > > >               > To: Fong, Man Wing; Maarten
> > > > > Vissers;
> > > > > Heiles Juergen
> > > > >           > > >               > Cc:
> > > > > [email-masked]
> > > > >           > > >               > 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"
> > > > > <[email-masked]>
> > > > >           > > >               > 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
> > > > >           > > >               > >
> > > > >           > > >               > > From:       ashritha
> > > > > thirumalai
> > > > > [mailto:[email-masked]]
> > > > >           > > >               > > Sent:       Friday, May
> > > > > 11, 2001
> > > > > 11:55 AM
> > > > >           > > >               > > To: Maarten Vissers;
> > > > > Heiles Juergen
> > > > >           > > >               > > Cc: 'ashritha thirumalai';
> > > > >           > > >               > >
> > > > > [email-masked]
> > > > >           > > >               > > 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
> > > > > <[email-masked]> 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:[email-masked]]
> > > > >           > > >               > > > > > Sent: Monday, May
> > > > > 07, 2001
> > > > > 9:05 PM
> > > > >           > > >               > > > > > To:
> > > > > [email-masked]
> > > > >           > > >               > > > > > Cc:
> > > > > [email-masked]
> > > > >           > > >               > > > > > 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
> > > > >           > > >               > > > > >
> > > > > [email-masked]
> > > > >           > > >               > > > > >
> > > > >           > > >               > > >
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >           > > >               > > > >
> > > > >           > > >               > > > >
> > > > >           > > >               >
> > > > > _______________________________________________
> > > > >           > > >               > > > > IP-Optical mailing
> > > > > list
> > > > >           > > >               > > > >
> > > > > [email-masked]
> > > > >           > > >               > > > >
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > 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:[email-masked]
> > > > >           > > >               > > >
> > > > > 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
> > > > >           > > >               > >
> > > > > [email-masked]
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > 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
> > > > >           > > >               >
> > > > > [email-masked]
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > 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
> > > > >           > > [email-masked]
> > > > >           > >
> > > > 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
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Thu, 17 May 2001 13:46:50 +0200

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.

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 17 May 2001 09:13:11 -0400

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.