RE: Please Clarify Doubts regarding RGT & RNC

[Vishal Sharma <vishal@JasmineNetworks.com>]

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.

 
>