Re: Please Clarify Doubts regarding RGT & RNC

[sambasiva mantha <sambu.mantha@usa.alcatel.com>]

Vishal,

As  you pointed at the end of the email, if a speciality funcitionality is not
required for "bundling" group type, then why there is a need for
distinguishing the group as such. In case of a SONET DCS the bundling has a
quite a unique function (see GR-2996). Once a group of STS-1s which must be
contigous, are defined as part of a bundle, the DCS does not allow the
operator to separate these STS-1s out in the sense they have to come in on one
input port (OC-n say) and all the STS-1s in the bundle have to cross connected
to the same outgoing output port (OC-m).

Sambu


Vishal Sharma wrote:

> Manoj,
>
> Some clarifications follow...
>
> -Vishal
>
> > -----Original Message-----
> > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> > Sent: Monday, March 19, 2001 3:35 PM
> > To: ccamp@ops.ietf.org
> > Subject: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > Hi All,
> >         The GMPLS draft
> > "draft-ietf-mpls-generalized-signalling-02.txt"
> > defines different values for RGT (Requested Grouping Type) viz.
> > Virtual Concatenation, Contiguous standard concatenation, Contiguous
> > arbitrary concatenation, Bundle.
> > How does the implementation of a control plane differ if it receives
> > different RGT values ?
>
> The implementation of the control plane should not differ based on
> different RGT values, the implementation of the data plane is what
> differs in all of these cases, because each RGT value controls how
> the data bearing channels are  treated by the end nodes and the
> intermediate nodes.
>
> For example, for virtual concatenation, the intermediate nodes treat
> the virtually
> concatenated channels as they would treat independent channels. The
> end points, however, treat these channels as "bonded" together, and must
> have hardware and software support to "glue" the data arriving on these
> channels together appropriately. (For instance, the hardware must
> support compensation for the differential delay that the component
> channels of the virtually concatenated stream may suffer.)
>
> > Another field RNC (Reuested Number of
> > Components) defines the number of such components requested.
> > My understanding is that if RNC is 2 and signal type is STM-1. Then it
> > means that 2 STM-1 signals are requested and these are concatenated
> > according to the RGT specified.
>
> Your understanding is correct.
>
> > Does this mean, the number of labels
> > requested depend on the RNC field ?  This means that is RNC is "X",
> > then "X" number of labels are to be returned in Label Mapping message
> > and the labels returned should be in accrodance with the requested
> > signal type.
>
> Not quite. The number of labels will be determined by a combination of
> the RNC and RGT.
>
> 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.
>
> If RGT = contiguous standard or contiguous arbitrary concatenation, then
> only a _single_ label is returned (that one that denotes the time slot at
> which the first of the concatenated channels begins).
>
> If, however, RGT = virtual concatenation or bundle, then 3 labels (or
> # of labels = RNC in the general case) will
> need to be returned in the label mapping message (namely, the times slots
> that denote where _each_ of the component STS-1s of the STS-3 signal is to
> be placed, since in these cases the component STS-1s need not occur in
> contiguous time slots).
>
> > Please clarify these doubts.
>
> Hope the above helps.
>
> > Can somebody please brief me on grouping type Bundle ?
>
> "Bundle" is nothing but an optimized way of simultaneously
> setting up multiple, independent
> SONET channels across a SONET network. Thus, in my example above, if
> RGT=bundle, what would really be setup in the SONET network would be
> three channels of STS-1 granularity, where each would be totally
> independent of the others, both at the intermediate nodes and at
> the end nodes.
>
> If, however, RGT=virtual concatenation, then what would really be
> setup in the SONET network would again be 3 channels of STS-1
> granularity, which to the intermediate nodes would be no different
> from the case above. To the end nodes, however, it would mean that
> they need to have the capability to handle virtually concatenated
> SONET channels (which means they need to be capable of appropriately
> dividing traffic across them [at the input], and "glueing" them back
> together [at the output]).
>
> > Is there any additional capability required in the network for
> > supporting different types of grouping types (RGTs) ?
>
> Not sure what you mean by "additional" capability? In "addition"
> to what?
>
> For contiguous standard concatenation, the network nodes need to
> be able to support standard SDH/SONET concatenation.
> For continuous arbitrary concatenation, the network nodes involved
> in the establishment of such a channel, need to be able to support
> arbitrary concatenation.
> For virtual concatenation, the intermediate nodes through which
> the channle passes need no additional functionality, but the
> end nodes must be able to support the processing of virtually
> concatenated channels.
> For bundling, absolutely no special functionality is required
> in either the intermediate nodes or the end nodes.
>
>
> >