Re: Please Clarify Doubts regarding RGT & RNC

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Vishal & Sambu,

I would like to add a bit to this discussion.

First some background:
For those familiar with functional modeling (and I recommend
it to all as an excellent tool for understanding communication
networks) there are three (or maybe four) functional considerations
that must be addressed in setting up a trail.
1) the type of characteristic information (which is necessary to 
   determine which link connections can support the connection)
2) the type of trail termination function (which must be matched 
   at the trail endpoints)
3) the client characteristic information and type of adaptation 
   (which may be separate considerations or bound together, and
   also must be matched at the endpoints)

Generally, intermediate nodes need only know 1), and possibly parts
of 2) if they support non-intrusive monitoring.  The endpoints
need to be able to exchange info about 2) and 3).

The current signaling structure, however, does not provide separate
fields for each of these areas.  There are only Signal Type and GPID
fields.  Signal Type encodes 1) and parts of 2), and GPID encodes 3).

A similar encoding is being used with RGT (that is, combining
information needed in transit nodes and end nodes into one field).
Thus (as has been explained) the difference between virtual
concatenation and bundling is relevant to the endpoints and not
the transit nodes.

Now to my point:
The RGT field is also required to distinguish between differing
connection requirements in transit nodes, and this has not been
precisely explained yet.

Both virtual concatenation and bundling share the constraint that
the set of link connections used must all be within the same higher
order container.  This guarantees some degree of shared fate and 
limits delay difference.

I have stated this as a definition, but this is only one possible
constraint.  Other possibilities include:

a) the set of link connections must be within one bit stream, but 
   may be in different higher order containers,
b) the set of link connections must go to the same neighbor (the
   loosest possible constraint within the signaling model), but
   they may be in different bit streams (even different fibers).

Eventually we must be precise about what the constraint is for
each RGT, and we may need to define additional RGT codepoints if
we need to encode different constraints.  Note: there may be a
label signaling problem if constraint b) is required.

Contiguous concatenation types have the specific constraint that
the set of components be treated as a single byte stream in transit
nodes (relative to pointer adjustment, etc.) and this implies the
components must all be within the same higher order container.

I think the difference between standard and arbitrary contiguous
concatenation should only be in the number of components allowed.
Timeslot flexibility is a local constraint between neighbors, and
both standard and arbitrary concatenated signals can make use of
flexible timeslot allocation, if supported.  Given this, we may
need to have a way to negotiate support for timeslot flexibility 
between neighbors (via LMP?) independently of the signaling of a
specific LSP.

Regards,
Ben

sambasiva mantha wrote:
> 
> 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.
> > > >
> > > >
> > > > >
> > >