RE: Please Clarify Doubts regarding RGT & RNC

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

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.
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. The case of virtual concatenation and what bundling means needs some further discussion. See the emails on "SDH/SONET concatenation signal types".

Regards

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.