[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please Clarify Doubts regarding RGT & RNC
Ben,
this is the second part of my response on RGT&RNC coding.
regards
Juergen
> -----Original Message-----
> From: Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> Sent: Thursday, March 29, 2001 6:26 PM
> To: Heiles Juergen
> Cc: sambasiva mantha; Vishal Sharma; 'manoj juneja'; ccamp@ops.ietf.org
> Subject: Re: Please Clarify Doubts regarding RGT & RNC
>
<snip>
> > > > I agree with you that the RTG field combines different types of information. Contiguous concateantion
> > > > is a characteristic information and should be coded into the signal type. As I mentioned before a
> > > > STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> > > > STS-3c-SPE into the signal type and RTG. A different coding for identical signals.
> > >
> > > We have gone back and forth on this topic. Originally STS-3c was a concatenated
> > > signal, then we
> > > changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
> > > and now it is
> > > coded as a concatenated signal once more. The current view is that it is
> > > cleaner to code it
> > > as a concatenated signal. In either case I think we will have some way to code
> > > the same signal
> > > in two ways. (If STS-3c is a separate signal type, it can still be coded as a
> > > concatenated type
> > > as well.)
> > [Juergen Heiles] You might use a dedicated field for contiguous concatenation,
> > but mixing it with bundling and virtual cocnatenation in one field has strange results. For example
> > you cannot setup a virtual concatenation of N STS-3c with a common route, while you can setup virtual
> > concatenation of N VC-4. I assume that virtual concatenation of STS-3c as it is equivalent to virtual
> > concatenation of VC-4s.
>
> We had some discussion of this among authors of GMPLS SONET/SDH signaling last week
> and one possibility considered was that STS-3c groups could be identified by applying
> the following convention: If the signal type is OC-3 with no transparency (that is, no
> line or section overhead included) AND some grouping type selected (e.g., virtual concatenation)
> THEN one would assume the path structure was STS-3c. This would also apply to other
> standard contiguous concatenated rates (STS-12c, VC4-4c, etc.). What do you think?
[Juergen Heiles] It looks strange to me to introduce into the first version of a specification that is still in draft state already a work around. As we still have the opportunity we should fix it properly. Is there any reason no to do it?????
In the current definitin OC-N path group means all STS-1/Xc-SPE in the OC-N. How would you address a virtual concatenation of 2 STS-3c-SPE in a OC-192 signal or virtual concatenation of arbitary contiguous concatenation?
Another concern is interworking between the US (SONET) and Europe (SDH). If we have a common coding for STS-3c and VC-4 virtual concatenation at least for the RTG&RNC field it makes live easier. If we introduce signal types for contiguous cocnatenation we could even use the same code for STS-3c and VC-4, STS-12c and VC-4-4c and so on. Only the LSP encoding would be different.
Virtual and contiguous concatenation are different. As Neil mentioned contiguous cocnatenation is a layer network of its own and as such needs its own signal type or a n additional contiguous concatenation field to the signal type.
Virtual cocnatenation is not a network layer of its own. Only the end notes have to care about it. You are limitng yourself from the beginning by combining the two.
So why not do it straight forward. Add signal types for STS-1-Nc-SPE and VC-4-Nc or add a number field to the STS-1-3c-SPE and VC-4 signal type which defines the number of contiguous concatenated signals. As discussed before you don't need a special indication for arbitary concatenation.
Bundling for virtual concatenation and othe pruposes has its own field.
> >
> There is also a proposal to add another level of grouping by adding a multiplier field.
> This would indicate that some number of grouped signal types is requested (e.g., a number
> of arbitrary contiguous concatenated signals -- say 10xSTS-7c). This is essentiually
> a second level of grouping, with no type or routing constraint differentiation.
[Juergen Heiles] What does this mean that the second level of grouping doesn't require common routing?
> <snip>