RE: Please Clarify Doubts regarding RGT & RNC

[Hai Vodinh <HVoDinh@turinnetworks.com>]

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
>