[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
From: Zhi-Wei Lin [mailto:firstname.lastname@example.org]
Sent: Tuesday, March 20, 2001 12:17 PM
To: Vishal Sharma
Cc: 'manoj juneja'; email@example.com
Subject: Re: Please Clarify Doubts regarding RGT & RNC
> > 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
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") ;-)