Re: Please Clarify Doubts regarding RGT & RNC

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

Hello Jeurgen,

I think we are in general agreement.  A few clarifications are included below.

Regards,
Ben

Heiles Juergen wrote:
> 
> Ben,
> 
> the characteristic information and the trail termination function are directly related as the
> characteristic infromation is generated/terminated by the trail termination function. So I don't
> see a need for additional trail termination information.

Some trail termination information is not currently included in the signaling,
and probably should
be.  For example, the Trail Trace Identifier should be configured the same way
at source and sink,
but is not currently in the signaling spec (but certainly not as part of Signal
Type). Also Payload 
ID should be set properly, but this can be inferred (translated) from the GPID
that is signalled.  
I don't know if there is other trail termination info that should be signalled
between the endpoints.  
Do you have any thoughts on this?

> 
> I agree with you that the RTG field combines different types of information. Contiguous concateantion
> is a characteristic information and should be coded into the signal type. As I mentioned before a
> STS-3c-SPE in SONET is a VC-4 in SDH. CUrretnly the VC-4 iscoded into the signal type and the
> STS-3c-SPE into the signal type and RTG. A different coding for identical signals.

We have gone back and forth on this topic.  Originally STS-3c was a concatenated
signal, then we
changed it to a separate signal type (for the standard values 3, 12, 48, etc.),
and now it is
coded as a concatenated signal once more.  The current view is that it is
cleaner to code it
as a concatenated signal.  In either case I think we will have some way to code
the same signal
in two ways.  (If STS-3c is a separate signal type, it can still be coded as a
concatenated type
as well.)

> I also agree with you on arbitary concatenation. It is contiguous concatenation. The signal type can
> clearly identify the type of contiguous concatenation (e.g. STS-12c-SPE or STS-15c-SPE). The time slot
> allocation is  a local matter for the link between two nodes and we might have other restrictions in
> time slot allocation or wavelength allocation in WDM systems.
>
> The RGT is then only needed for bundles with common routing. Common routing should be a general concept
> independent of the technology (SDH/SONET, OTN, ...). As you mentionedcommon routing could mean the same
> server layer connection, the same physical signal, the same fiber, the same duct, the same network
> elements. One has similar options as for diverse routing.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From: Ben Mack-Crane [SMTP:Ben.Mack-Crane@tellabs.com]
> > Sent: Friday, March 23, 2001 5:14 PM
> > To:   sambasiva mantha
> > Cc:   Vishal Sharma; 'manoj juneja'; ccamp@ops.ietf.org
> > Subject:      Re: Please Clarify Doubts regarding RGT & RNC
> >
> > 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 in> put], 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.
> > > > > >
> > > > > >
> > > > > > >
> > > > >
> >