[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please Clarify Doubts regarding RGT & RNC
Vishal, Hai,
I fully agree with you for the LCAS case. With LCAS you can add or remove STS-SPEs or VT to increase or decrease the bandwdidth. But note that a new SPE/VT could take the same route or a diverse route as the already established SPE/VT cnnections.
Juergen
> -----Original Message-----
> From: Vishal Sharma [SMTP:vishal@JasmineNetworks.com]
> Sent: Friday, March 23, 2001 9:52 AM
> To: 'Hai Vodinh'; ccamp@ops.ietf.org
> Cc: Juergen.Heiles@icn.siemens.de; 'neil.2.harrison@bt.com'
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
>
> Neil and Juergen,
>
> I think Hai has already made the point. When I was talking about change
> in bandwidth, I was implicitly assuming that Hai was referring to the
> virtual concatenation case. (Correct me if I am wrong, but I didn't
> think there was any other situation, proposed in the standards,
> where you could dynamically change the bandwidth of an existing SONET
> channel.)
> [Although, one might conceive of situations where implementations that
> support
> arbitrary concatenation might allow for one to increase the bandwidth
> of an existing circuit simply by adding more STS-1s to it. For instance,
> if one was switching an arbitrarily concatenated STS-5, and wanted to make
> it an STS-7 (assuming that the 2 other STS-1s were contiguous with the
> 5 STS-1s that formed the STS-5 signal), one might be able to do it.]
>
> I understand that if you wanted to setup
> a totally different SONET/SDH channel (with a different bandwidth),
> you would need to go the "create new->switch_to_new->delete old"
> route.
>
> Also, Neil, I did read your earlier email. The reason I did not think that
> that comment applied here was because (I thought) the current discussion
> was only in the context of virtual concatenation with LCAS,
> since that appears to be the only scheme which allows for the dynamic
> addition or deletion of channels to an existing (virtually
> concatenated) connection.
>
> -Vishal
>
> > -----Original Message-----
> > From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> > Sent: Thursday, March 22, 2001 12:56 PM
> > To: ccamp@ops.ietf.org
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Neil
> >
> > The 'create_new->switch_to_new->delete_old' scheme seems to
> > me to be fairly
> > inefficient mechanism for making small bandwidth change to large pipe.
> > Think about addimg 3 sts-1s to a sts-1-43v pipe, you would
> > have to first
> > make a sts-1-46v, switch the client signal over, then delete
> > the original
> > sts-1-43v. I do agree that it is a more straight forward way
> > to achieve the
> > goal, it is probably also simpler to keep track of the sts-1s
> > also. I think
> > however if bandwidth modification (to existing pipe) is an
> > important service
> > then we need a more efficient mechanism. I'm not saying that
> > this would be
> > easy.
> >
> > My question to carriers would be: is b/w modification for virtually
> > concatenated SPE important? in the short term & long term?
> >
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Thursday, March 22, 2001 1:38 AM
> > To: Juergen.Heiles@icn.siemens.de; vishal@JasmineNetworks.com;
> > HVoDinh@turinnetworks.com; zwlin@lucent.com
> > Cc: ccamp@ops.ietf.org; GregB@ciena.com
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Vishal....you asked (in mail below) for operator input.....perhaps you
> > missed this item I posted Wed 14/03/2001 13:35 on the thread
> > 'RE: Three
> > GMPLS related IDs' against this ID from Yangguang Xu
> > http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-
> > intra-domain-0
> > 0.txt
> >
> > <prior text snipped NH>
> > 10 In section 5.4.1.5 'actions' on trails are defined. For a CO
> > network with fixed BW selection at trail creation time it is
> > very hard to
> > see what a 'modify' action could be....other than perhaps a change of>
> > restoration priority and/or change of dedicated back-up
> > trail/resource. If
> > there is any notion of (working) BW change here (be it a
> > scalar magnitude
> > change, ie same route, or a vector change, ie new route (with
> > or without a
> > scalar magnitude change)), it would seem to me that this is
> > really a new
> > pair of 'create_new->switch_to_new->delete_old' actions. I
> > note however
> > that this has been marked as TBD, but I think it would help
> > if it was made
> > clear that BW changes cannot (IMO) be a single 'modify' action.
> > <post text snipped NH>
> >
> > So in essence I agreed with what Juergen is saying.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> > > Sent: 22 March 2001 09:07
> > > To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Vishal,
> > >
> > > in the circuit switched world he connection has a fixed
> > > bandwidth. You cannot change the bandwidth. You have to tear
> > > down the connection and set-up a new one with a different
> > > bandwidth. For example if you want to change from VC-3
> > > (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is
> > > released and a VC-4 connection is setup. The route could be
> > > different as some equipment migth support VC-3 but not VC-4s
> > > or vice versa.
> > > Virtual concatenation toegether with LCAS provides
> > > flexibility in certain steps. However it applies only to the
> > > end points as you mentioned. Between the end points you still
> > > setup connections with fixed bandwidth.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > > > -----Original Message-----
> > > > From: Vishal Sharma [SMTP:vishal@JasmineNetworks.com]
> > > > Sent: Thursday, March 22, 2001 9:36 AM
> > > > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > > > Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > > >
> > > > Hai,
> > > >
> > > > Yes, now that you mention it, it probably is an important
> > > capability.
> > > > (Although,
> > > > I am not sure how soon it needs to be made available.)
> > > > [Again, any carriers listening on this channel?? "Hello,
> > calling all
> > > > carriers... we need some service provider input here."]
> > <snipped to end NH>
> >