[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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."]
>
> In the packet world, this was envisaged to be achieved as follows.
> If one uses RSVP-TE, a different SENDER TSPEC with a modified bandwidth
> parameter
> in the PATH message would be expected to change the reservations along the
> path. Thus, after at most one round trip delay, the sender could start
> transmitting
> data at the new (greater or lesser) rate. (Or more accurately, the sender
> could start transmitting with the new _traffic parameters_, with the
> assumption
> that the admission control at the intermediate nodes has done its job and
> reserved adequate resources for the modified parameters.)
>
> Now whether the exact same mechanism works for the TDM case, or is adequate
> for the TDM case, I think needs more thought.
>
> -Vishal
>
> > -----Original Message-----
> > From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> > Sent: Wednesday, March 21, 2001 12:00 PM
> > 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, Greg,
> >
> > Thanks for the clarification on the difference between VC and
> > bundling. On
> > my last question, isn't the abibility to get additional
> > bandwidth for an
> > already established signal a crucial requirement for the type of
> > bandwidth-on-demand or more appropriately
> > bandwidth-modification service
> > that we are thinking of today?
> >
> > Thanks,
> > Hai
> >
> > -----Original Message-----
> > From: Vishal Sharma [mailto:vishal@JasmineNetworks.com]
> > Sent: Tuesday, March 20, 2001 11:45 PM
> > To: 'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Hi Hai,
> >
> > Greg has already provided an answer. I just wanted to add that in
> > my initial explanation to Manoj, I did point out what the difference
> > was between virtual concat. and bundling. For the intermediate
> > nodes, there is no difference, the differene only comes in for
> > the end points, which in the virtual concat. case have to know
> > which channels are virtually concatenated, and compensate for
> > differential delay across these channels.
> >
> > > -----Original Message-----
> > > From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> > > Sent: Tuesday, March 20, 2001 5:14 PM
> > > To: 'Zhi-Wei Lin'; Vishal Sharma
> > > Cc: ccamp@ops.ietf.org
> > > Subject: RE: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > I tend to agree with Zhi-Wei that when you need to set up multiple
> > > connections these should be done separately (except perhaps
> > > in the virtual
> > > concatenated case) to keep the signaling protocol simple.>
> > >
> > > I'm following the discussion and still don't have a clear
> > > idea why both
> > > virtual concatenation and bundling RGT are needed. What is
> > > the difference
> > > between the two types?
> > >
> > > Here is another question: let's say I have a STS-1-4v SPE
> > > already set up,
> > > now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how
> > > do I signal to
> > > the network that the additional 2 STS-1s need to be co-routed
> > > with the other
> >
> > I am not sure that there is any easy way to day to perform such
> > signaling.
> >
> >
> > >
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > > Sent: Tuesday, March 20, 2001 12:17 PM
> > > To: Vishal Sharma
> > > Cc: 'manoj juneja'; ccamp@ops.ietf.org
> > > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > >
> > >
> > > Hi Vishal,
> > >
> > >
> > >
> > > > > 3 STS-3: ??? How would you signal this? Not supported?
> > > >
> > > > What do you wish to signal here? Three groups of STS-3 each?
> > > > What does it mean? The STS-3 is a bundle, and you wish to signal
> > > > a bundle of bundles?
> > > >
> > > > If that is so, and unless I am missing something, I think
> > you'd have
> > > > to signal them separately.
> > > >
> > > > BTW, I wasn't immediately able to see how this would be signaled
> > > > even using the codepoints proposed in
> > > > draft-lin-ccamp-ipo-common-label-request-01.txt.
> > > >
> > >
> > > I don't understand how that is a bundle. STS-3 as defined in
> > > the T1.105
> > > is the entire signal. So then if you can signal multiple STS-1s, my
> > > question was why is this not supported for STS-3 or other STS-X.
> > >
> > > Right, draft-lin assumes that when you need to set up multiple
> > > connections, these are done separately. Adding the capability for
> > > multiple connection set-ups as part of the signaling
> > mechanism is not
> > > really necessary. Remember that the signaling mechanism is
> > not the GUI
> > > to the customer. The GUI that the customer sees can provide that
> > > feature. The interface from GUI to the signaling can be a
> > > batch function
> > > that sets up the multiple connections. This simplifies the signaling
> > > protocol, allows "bundling" of different connection types
> > > set-up at once
> > > (e.g., if customer wants to set up 3 STS-3c, 4 STS-7v, and 2
> > > STS-48c at
> > > once) via a batch process, and does not complicate the protocol from
> > > having to handle this issue.
> > >
> > > Some of the points mentioned by Ewart in the OIF discussion
> > was: when
> > > multiple connections are handled at once, what are the
> > characteristics
> > > of these connections? Do they all terminate at the same
> > location? Are
> > > they all co-routed or separately routed? How many labels do
> > > you return?
> > > If one label is returned, what happens when one connection
> > > failed? What
> > > if the multiple connections have different destinations? etc.
> > >
> > >
> > > > > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > > > > arbitrary)
> > > > > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> > > > >
> > > > > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> > > >
> > > > Again, as things stand today, you'd have to signal this
> > separately.
> > > >
> > > > First, is there a requirement to signal these this way? Assuming
> > > > there is, is there a proposal that allows for that?
> > > >
> > >
> > > I wasn't sure whether there is requirement or not. I was
> > > extending your
> > > example with what was offered currently. My view was that it
> > > seems that
> > > some capabilities are available to certain signal types and
> > > not to other
> > > signal types. We probably need to extend or clarify the text,
> > > or adopt a
> > > different position in terms of what should and should not be
> > > provided by
> > > the signaling protocol, and leave "added features" to >
> > > separate functions
> > > (the batch process I mentioned above).
> > >
> > >
> > > > I cannot see how
> > > draft-lin-ccamp-ipo-common-label-request-01.txt would
> > > > do it either, since the RNC has been absorbed into the signal type
> > > > in that case, and not all cases are enumerated.
> > > >
> > >
> > > See above for comment.
> > >
> > > > > 1 STS-7v: RNC=7, RGT=1 (virtual)
> > > > >
> > > > > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> > > >
> > > > Same as the two above.
> > > >
> > >
> > > See above (sorry, too many "aboves") ;-)
> > >
> > > Zhi
> > >
> >