[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Greg et all,
By taking a look on the version -00 of the draft (published in October
2000 - at that time draft-ietf-mpls-generalized-signalling-00.txt
includes sonet/sdh extensions) it was clearly mentioned "arbitrary
contiguous concatenation" in the document !
[...]
Requested Grouping Type (RGT): 4 bits
This field indicates the SDH/SONET type of grouping requested
for the LSP, it is used to constraint the type of concatenation.
The values are defined in the following table:
Value Grouping type
----- ----------------------------------
0 (Implies no concatenation/bundling when RNC = RT = 0)
1 Virtual concatenation
2 Contiguous standard concatenation
3 Contiguous arbitrary concatenation
4 Inverse Multiplexing
[...]
So either i don't understand what "start out" means or you probably
refer to an older version of the document or... but clearly the
meaning of "contiguous arbitrary concatenation" has not change since
then.
The reference at that time was the document draft-mack-crane-gmpls-
signaling-enhancements-00.txt - section 6.
[...]
Virtual concatenation requires co-routing and implies a bonding
function at the endpoints of the group. For contiguous standard
concatenation, there must be a standard number of components
(4, 16, 64, etc. for SDH; 3, 12, 48, etc. for SONET), and they
must be in one higher order container. For contiguous arbitrary
concatenation, the number of components is arbitrary (2, 3, 4, à)
and they still must be routed in one higher order container.
[...]
However in your draft draft-bms-sdhsonet-mpls-control-frmwrk-00.txt
(published in November 2000), you mention the term "flexible" or
"arbitrary concatenation" in section 6.1.2:
[...]
Due to these disadvantages some SONET framer manufacturers now
support "flexible" or arbitrary concatenation, i.e., no restrictions
on the size of an STS-Mc (as long as M <= N) and no constraints on the
STS-1 timeslots used to convey it, i.e., the signals can use any
combination of available time slots.
[...]
So, it does not surprise me that this discrepancy occurs... since
we speak about different types of concatenation and "arbitrary
concatenation" is a third type of concatenation (in addition to
contiguous and virtual concatenation defined in ITU-T/T1 standards)
Regards,
Dimitri.
"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
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard