RE: Please Clarify Doubts regarding RGT & RNC

[Vishal Sharma <vishal@JasmineNetworks.com>]

Zhi,

If you were merely extending my example, then the problem will be solved
by adding a new signal type for STS-3 (if, as you say below, T1.105 defines
an STS-3 as an entire signal).

By looking at your questions, I got the impression that you knew that
the functionality required by your examples was needed, and further
that you meant that your current proposal covers it.
Since neither draft currently covers it, if we determine that multiple
bundles can be setup as a "batch" process at the application level, but
will be handled via separate signaling requests at the protocol level
then we are in agreement.

For some other comments, pl. see below.

-Vishal
> -----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.

I would assume that an assumption in either virtually concatenated or
bundled connections clearly is that the start and terminate at the
same end nodes! 
Whether they are all co-routed or separately routed
may be determined by end node that requests their setup. 

If you
use virtual concatenation you could presumably return multiple
labels, one each of each of the channels comprising the virtually
concatenated signal.

I am not sure that in the bundle case or the virtually concatenated case
one would return only one label. Maybe one may get by with returning
just one, if by some chance the concatenated or bundled channels just
happen to be contiguous.

Not sure by what you mean by "what happens when one connection fails"? What
happens to what? and with respect to what?
Even if a connection fails, the head end will still know which slot numbers
contain healthy channels that are components of a virtually concatenated
channel or bundled channels.


> > > 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
>