Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

From: "Bernstein, Greg" <[email-masked]>
Date: Wed, 16 May 2001 08:33:12 -0700

Hi in the draft 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

---

From: "Mannie, Eric" <[email-masked]>
Date: Wed, 16 May 2001 19:34:14 +0200

Hi all,

That's right Greg, thanks.

I am guilty, I introduced this bug when I updated the text I believe. Sorry.

I'll correct it.

Kind regards,

Eric

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 5:33 PM
To: [email-masked]; [email-masked]
Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

Greg B.

---

From: "Mannie, Eric" <[email-masked]>
Date: Wed, 16 May 2001 21:44:12 +0200

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:[email-masked]]
Sent: Wednesday, May 16, 2001 5:33 PM
To: [email-masked]; [email-masked]
Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

Greg B.

---

From: Heiles Juergen <[email-masked]>
Date: Thu, 17 May 2001 09:45:32 +0200

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

> From:	Michael Waldo [SMTP:[email-masked]]
> Sent:	Thursday, May 17, 2001 12:42 AM
> To:	Bernstein, Greg
> Cc:	'Mannie, Eric'; [email-masked]; [email-masked]
> 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.
> >                 From:   Mannie, Eric [mailto:[email-masked]]
> >                 Sent:   Wednesday, May 16, 2001 12:44 PM
> >                 To:     Bernstein, Greg; [email-masked]; [email-masked]
> >                 Subject:        RE: Small issue on
> > draft-ietf-ccamp-gmpls-sdh-00.txt
> >
> >                 Dear All,
> >
> >                 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:
> >

---

From: Hai Vodinh <[email-masked]>
Date: Wed, 16 May 2001 16:04:43 -0700

Michael,

Greg's (1) has the additional restriction of "one big signal within a single
SONET Line (SDH MS)" so it is not like Virtual Concatenation which has no
such restriction.  Base components (sts-1, sts-3c) of sonet vc signals can
have diverse paths.

Hai

-----Original Message-----
From: Michael Waldo [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 3:42 PM
To: Bernstein, Greg
Cc: 'Mannie, Eric'; [email-masked]; [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

(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:

>                 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
>                 virtual concatenation because there is no restriction
anyway
> on the timeslot
>                 indicates the number and types of signals to be
concatenated
> and the
>                 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
>                 This does not reflect the intent of arbitrary
concatenation-
> arbitrary, size