[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
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:mwwaldo@flash.net]
Sent: Wednesday, May 16, 2001 3:42 PM
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 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