Re: Please Clarify Doubts regarding RGT & RNC

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

Vishal,

I understand what is "bundling" group is for. What I was questioning was your
statement that no special handling is required for the bundling. They are
treated the same at the end nodes and at the intermediate nodes. What I was
pointing out was that when they are tagged as "bundling" group, then the
intermediate nodes also have to treat it specially.

Sambu


Vishal Sharma wrote:

> Sambu,
>
> The "bundling" group type is defined to allow for the setup of multiple
> channels in parallel, such as three STS-1s in parallel, instead of setting
> up each individually. (Note that the draft currently allows for
> the bundling of only those channels that are in the same higher-order
> container.) This also allows the operator to control the fate of these
> bundled channels.
>
> -Vishal
>
> > -----Original Message-----
> > From: sambasiva mantha [mailto:sambu.mantha@usa.alcatel.com]
> > Sent: Wednesday, March 21, 2001 9:09 AM
> > To: Vishal Sharma
> > Cc: 'manoj juneja'; ccamp@ops.ietf.org
> > Subject: Re: Please Clarify Doubts regarding RGT & RNC
> >
> >
> > 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.
> > >
> > >
> > > >
> >