[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Please Clarify Doubts regarding RGT & RNC
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.
> >
> >
> > >
>