RE: Please Clarify Doubts regarding RGT & RNC

[Vishal Sharma <vishal@JasmineNetworks.com>]

Zhi-Wei,

Good points all. 
Please see below...

-Vishal

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Monday, March 19, 2001 10:34 PM
> To: Vishal Sharma
> Cc: 'manoj juneja'; ccamp@ops.ietf.org
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Hi Vishal,
> 
> 
> 
> > To understand this, let's consider the setting up of an STS-3 SONET
> > channel (which is transparent
> > only at the path level, so that line and section overheads 
> are not to be
> > preserved across SONET equipment), and see what happens in 
> the various
> > cases.
> > In every case, the signal type = STS-1, and the RNC = 3.
> > 
> 
> So, in your example, for:
> 
> 1 STS-3: RNC=3, RGT=0
> 3 STS-1: RNC=3, RGT=4 (bundle)
> 
> 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.

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

> 1 STS-7v: RNC=7, RGT=1 (virtual)
> 
> ==> 7 STS-7v: ??? How would you signal this? Not supported?

Same as the two above.


> If the identified signals are really not supported, then it would seem
> that there is some inconsistency and maybe (?) not well 
> organized fields
> that arbitrarily supports certain combinations and not others...

I think what the draft does at present is that it supports some base
combinations, which will allow you to realize the setting up of the channels
that you mention below (as I've suggested above).

I am not sure if there is a desire (service providers please speak up!) to
set up the types of channels you suggest above, in _one round_ of signaling.

(It could certainly be argued that they are valid choices to want to
signal.)
If there is a requirement from SPs, then the signal
types/RGT/RNC might need to be extended to cover these cases.

> Am I correct? Do we need to fix this to make it consistent in terms of
> supporting "like" signal types?

See above.