RE: Please Clarify Doubts regarding RGT & RNC

[Vishal Sharma <vishal@JasmineNetworks.com>]

> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> Sent: Tuesday, March 20, 2001 2:33 AM
> To: 'Vishal Sharma'; 'Zhi-Wei Lin'
> Cc: 'manoj juneja'; ccamp@ops.ietf.org
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> the problem is the mix of bundle and concatenation 
> information in the RTG. This allows you to request a bundle 
> of non-concatenated signals (e.g. STS-3, VC-4, VC-3) but not 
> a bundle of concatenated signals (e.g. STS-3c, VC-4-4c, 
> VC-4-16v). This is strange as a VC-4 and a VC-4-4c are not 
> different from a network point of view, except for the 
> bandwidth and a VC-4 is the same as a STS-3c-SPE. If bundling 
> is introduced it should apply to all signal types.

Agreed. I just pointed out below that in the GMPLS signaling
functional specification, as it stands, it is not possible to
request bundles of bundles (BTW, that was one of the cases
Zhi had), or bundles of concatenated signals.

> The concatenation information should therefore be part of the 
> signal type as proposed in 
> draft-lin-ccamp-ipo-common-label-request-01.txt. Bundling is 
> needed it is indicated by an RNC>1. 

Where is the RNC in draft-lin...? What I don't understand about
the encoding in this draft is how it will allow for the case you
have above?

> The case of virtual 
> concatenation and what bundling means needs some further 
> discussion. See the emails on "SDH/SONET concatenation signal types".

On which mailing list. CCAMP? (I ask because I had some problems receiving
CCAMP emails recently, and have missed quite a few in the last couple days.)

-Vishal

> 
> Juergen
> 
> > -----Original Message-----
> > From:	Vishal Sharma [SMTP:vishal@JasmineNetworks.com]
> > Sent:	Tuesday, March 20, 2001 8:50 AM
> > To:	'Zhi-Wei Lin'; Vishal Sharma
> > Cc:	'manoj juneja'; ccamp@ops.ietf.org
> > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > 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.
>