[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
It seems that we have some confusion concerning arbitary concatenation. That happens when we talk about something that is not standardized and proprietary. So next time we better get a detailed definiton of the proprietary solution before it is included in order to check if it fits the definitions.
Coming back to concatenation I see the following types:
Standard contiguous concatenation as defined in G.707 for VC-4 and in T1.105 for STS-1-SPE:
Uses X contiguous time slots within a STM/STS signal. x=4,16,64,256 for VC-4 and X=3,12,48,192, 768 for STS-1-SPE
The first time slot can only be at certain time slots.
The first time slot has a valid pointer , all other time slots have a concatenation indication. One set of path overhead is available for the whole signal.
-> we only need to identify the first time slot and the number of time slots (covered by GMPLS draft)
Virtual concatenation as defined in G.707 and T1.105 for every VC level:
Uses X time slots, which can be in any position and even distributed over everal STM/STS signals.
Every timeslot (individual signal) has its own pointer and path overhead and is treated indivdually at intermediate notes.
-> we need to identify all time slots (covered by GMPLS draft for a virtual cocnateantion that uses the same route for all individual signals)
Arbitary contiguous concatenation, not standardized extensiion of standard contiguous concatenation (that seems to be what is most peoples understanding of arbitary concatenation):
Same as standard contiguous concatenation, without the limits on X and the position of the first time slot
-> we only need to identify the first time slot and the number of time slots (covered by GMPLS draft)
Greg's arbitary concatenation (or non-contiguous contiguous concatenation); not standardized, proprietary solution (here I can only guess):
Uses X time slots which can be at any position within a STM/STS signal. The positons of the time slots have to be in ascending order. The first time slot has a valid pointer , all other time slots have a concatenation indication. One set of path overhead is available for the whole signal.
Some kind of in-band signaling (within the overhead) is required in order to identify the time slots that belong togehter if automatic adjustment of pointer processing to the signal type is needed
-> we need to identify every time slots
This signal type is not covered by the GMPLS draft. It is different from virtual concatenation as the signal processing (pointer, overhead) is different. As it is proprietary and not straight forward from the standard contiguous concatenation different implementations might exist that do not interwork and a identification for each implementation is required.
Juergen
> -----Original Message-----
> From: Michael Waldo [SMTP:mwwaldo@flash.net]
> Sent: Thursday, May 17, 2001 12:42 AM
> To: Bernstein, Greg
> Cc: 'Mannie, Eric'; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
>
> your (1) sounds more like virtual concatenation to me
>
> (2) is what I have considered to be arbitrary concatenation. This could be
> useful when compared to standard contiguous concatenation because it could make
> more efficient use of the bandwidth within the SONET line (SDH MS) eg, using an
> STS-2c when only 100Mbs is needed. Standard contiguous concatenation payload
> values being 3c, 12c, 48c, 192c for SONET.
>
> Considering virtual concatenation, arbitrary concatenation doesn't seem to have
> as much appeal (pretty useless).
>
> Has the term "arbitrary concatenation" been defined anywhere? I've seen
> contiguous and virtual definitions, but I looked through the references in this
> draft, (as well as G.707 and T1.105) and I could not find the "arbitrary"
> definition.
>
>
> -Waldo
>
>
> "Bernstein, Greg" wrote:>
>
> > We started out with the simple term "arbitrary concatenation" a while back
> > to mean arbitrary in size and in timeslots used. I'm not sure what was
> > meant when we added the "contiguous" to this. Was it:
> > (1) Treat this as one big signal within a single SONET Line (SDH MS),
> > with potentially arbitrary timeslots used.
> > (2) Treat this as one big signal within a single SONET line (SDH MS),
> > with the timeslot numbering lying within a single range, i.e., X through Y,
> > with X < Y.
> >
> > If (1) then we need a list of time slots. If (2) then only the beginning
> > time slot is needed. The problem with (2) is that it is a pretty useless
> > feature, i.e., doesn't prevent the need for re-grooming and seemed like a
> > mistake from the rather long gestation period for this specification rather
> > than something truly intended.
> >
> > Greg B.
> > Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > New phone: (510) 573-2237
> >
> > -----Original Message-----
> > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> > Sent: Wednesday, May 16, 2001 12:44 PM
> > To: Bernstein, Greg; ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: RE: Small issue on
> > draft-ietf-ccamp-gmpls-sdh-00.txt
> >
> > Dear All,
> >
> > Sorry I was confused, the original text of the draft is
> > correct:
> >
> > With any kind of ***contiguous*** concatenation there is one
> > big signal, so
> > one and only one label (pointer) is needed (otherwise it is
> > not a contiguous
> > concatenation). With any kind of virtual concatenation,
> > there are several
> > VC's, so one label (pointer) per VC is needed. Even if all
> > the VC's
> > virtually concatenated are contiguous (by coincidence) we
> > still need to
> > identify each of them.
> >
> > Arbitrary and standard concatenations are orthogonal with
> > contiguous and
> > virtual concatenations.
> >
> > Arbitrary means anything that is not standard.
> >
> > We use a code to differentiate between standard and
> > arbitrary contiguous
> > concatenation to avoid that a downstream node returns a
> > timeslot at a
> > position not supported by the upstream node. The upstream
> > node indicates the
> > number and types of signals to be concatenated and the
> > downstream node
> > cannot change it (it can just accept or refuse).
> >
> > We don't need a code to differentiate between standard
> > versus arbitrary
> > virtual concatenation because there is no restriction anyway
> > on the timeslot
> > positions that can return the downstream node. Again, the
> > upstream node
> > indicates the number and types of signals to be concatenated
> > and the
> > downstream node cannot change that (it can just accept or
> > refuse). SDH 1996
> > restricts the virtual concatenation to some well defined
> > signals, while SDH
> > 2000 allows everything that make sense. But for the previous
> > reasons we
> > don't need to differentiate between the two (thing about the
> > reason why you
> > put a signaling element in a signaling message).
> >
> > Agreed ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:GregB@ciena.com]
> > Sent: Wednesday, May 16, 2001 5:33 PM
> > To: ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt>
> >
> > Hi in the draf> t draft-ietf-ccamp-gmpls-sdh-00.txt it says:
> >
> > In case of any type of contiguous concatenation (e.g.
> > standard or
> > arbitrary concatenation), only one label appears in the
> > Label
> > field. That label is the lowest signal of the
> > contiguously
> > concatenated signal. By lowest signal we mean the one
> > having the
> > lowest label when compared as integer values, i.e. the
> > first
> > component signal of the concatenated signal encountered
> > when
> > descending the tree.
> >
> > In case of virtual concatenation, the explicit ordered
> > list of all
> > labels in the concatenation is given. Each label
> > indicates a
> > component of the virtually concatenated signal.
> >
> > This does not reflect the intent of arbitrary concatenation-
> > arbitrary, size
> > and placement of timeslots. Otherwise the main benefit of
> > arbitrary
> > concatenation, preventing re-grooming is lost. Corrected
> > text could read:
> >
> > In the case of standard contiguous, only one label
> > appears in the Label
> > field. That label is the lowest signal of the standard
> > contiguously
> > concatenated signal. By lowest signal we mean the one
> > having the
> > lowest label when compared as integer values, i.e. the
> > first
> > component signal of the concatenated signal encountered
> > when
> > descending the tree.
> >
> > In the cases of arbitrary or virtual concatenation, the
> > explicit ordered
> > list of all
> > labels in the concatenation is given. Each label
> > indicates a
> > component of the arbitrary or virtually concatenated
> > signal.
> >
> > Greg B.
> > Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > New phone: (510) 573-2237