[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ARE: [T1X1.5] arbitrary contiguous concatenation question



Hello Maarten,

I though that my e-mail was more about SDH, sorry if I was not clear :-)

Also you know (since you wrote the arbitrary concatenation section with me)
that the IETF is not defining any transport plane. We (you and me) gave a
description of our understanding of arbitrary concatenation.

Whatever are the exceptions that one can find in the transport plane
interoperability (not in IETF scope), it doesn't change the fact that many
arbitrary concatenated signals are useful and used (e.g. to transport 1 GE),
and for those signals there is no problem.

The issue of the STS-3c is an exception and don't break the general
mechanism. To solve this exception, there is an easy solution in the
signaling: return the list of labels for all timeslots (like in case of
virtual concatenation).

Also, I think that one should refrain to cc these e-mails systematically to
IETF, ITU-T and T1X1 mailing lists. I don't know what is the purpose of this
! That's the last time that I am doing it.

Those people interested into GMPLS can simply join the CCAMP mailing list
(see IETF web site, WG, CCAMP WG).

Kind regards,

Eric

-----Original Message-----
From: Maarten Vissers
To: Mannie, Eric
Cc: 'Heiles Juergen'; ccamp; t1x1.5; q11/15
Sent: 8/5/01 2:00 PM
Subject: Re: ARE: [T1X1.5] arbitrary contiguous concatenation question

Eric,

Let's discuss this issue during the IETF meeting in London. Being face
to face
its easier to illustrate that a STS-3c isn't using 3 physically
contiguous
timeslots.

For the standard contiguous concatenation (including STS-3c) there are
T1.105
and G.707 defining the timeslots used. But there are no transport plane
documents that define the timeslot allocation for arbitrary
concatenation. I.e.
is a STS-3a using physically contiguous timeslots or is it using the
same
timeslots a STS-3c would use?
As the gmpls-sonet-sdh document is the first and only standard
describing
arbitrary concatenation, interworking is only guaranteed when it is
unambiguous
which timeslots are being used.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Juergen and Maarten,
> 
> I don't understand the relationship between
> draft-ietf-ccamp-gmpls-sonet-sdh-01.txt and the problem that you are
talking
> about.
> 
> In addition, the IETF is not specifying any SDH/SONET interoperability
(Not
> at all in the GMPLS scope).
> 
> Also, I am not sure to understand why the abstract (B, A) notation of
G.707
> (used to have a clearer specification, and not used (transported) in
any
> protocol as far as I know) could imply that contiguous time-slots are
not
> contiguous anymore ?
> 
> The "Arbitrary" concatenation that you are speaking about is a
contiguous
> concatenation, time-slots are physically contiguous. I don't
understand the
> relevance of the SDH (B, A) notation in relationship with SONET in the
> context of the IETF. Anyway, contiguous time-slots will stay
physically
> contiguous even if you see an issue with the SDH G.707 (B, A) notation
> applied to SONET.
> 
> Also, "flexible arbitrary concatenation" (whatever it is - everybody
seems
> to have a different understanding) is not part of
> draft-ietf-ccamp-gmpls-sonet-sdh-01.txt.
> 
> I guess also that this discussion is relevant for the ITU-T and/or
T1X1, not
> for the ccamp mailing list (of the IETF).
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> Sent: Tuesday, July 24, 2001 4:28 PM
> To: 'Maarten Vissers'; ccamp
> Cc: t1x1.5; q11/15
> Subject: AW: [T1X1.5] arbitrary contiguous concatenation question
> 
> Maarten,
> 
> good point. Lets hear what the supporters of arbitrary concatenation
have to
> say.
> 
> Juergen
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Maarten Vissers [mailto:mvissers@lucent.com]
> > Gesendet: Dienstag, 10. Juli 2001 11:14
> > An: ccamp
> > Cc: t1x1.5; q11/15
> > Betreff: [T1X1.5] arbitrary contiguous concatenation question
> >
> >
> > All,
> >
> > draft-ietf-ccamp-gmpls-sonet-sdh-01.txt defines signalling
> > support for arbitrary
> > contiguous concatenation in appendix 3. Looking a bit more
> > into this arbitrary
> > concatenation from the transport plane, I came across a
> > question with respect to
> > the definition of "contiguous STS-1/AU-3 timeslots". Let me
> > introduce this
> > question:
> >
> > Figure 7-25/G.707 (10/2000) lists the AU-3 numbering (within
> > an STM-4) as
> > follows
> >
> >      Time          111
> >      Slot 123456789012123456789
> >
> >       B 123412341234123412341...
> >       A 111122223333111122223...
> >
> > AU-3 timeslots have a TimeSlot number and a (B,A) number,
> > with TS1 associated
> > with (1,1) and TS12 associated with (4,3).
> >
> >       Note - the figure in the pre-published version of G.707
> >       doesn't show the timeslot numbering in a correct manner.
> >
> > and the AU-4 numbering is as follows (figure 7-24/G.707)
> >
> >      Time
> >      Slot 123412341234123412341
> >
> >       B 123412341234123412341...
> >       A 000000000000000000000...
> >
> > An AU-4 [STS-3c] is as such essentially a "non-contiguous"
> > concatenation of
> > AU-3s [STS-1s]; i.e. every 4th AU-3/STS-1 is use; e.g. AU-4
> > (2,0) uses AU-3
> > timeslots 2,6,10 [i.e. (2,1), (2,2), (2,3)].
> >
> >
> > If we define STS-1 contiguous concatenation, which timeslots
> > are then used for
> > e.g. a STS-1-3c:
> >       i)  timeslots (1,1),(2,1) and (3,1) [TS1,TS2,TS3], or
> >       ii) timeslots (1,1), (1,2) and (1,3) [TS1,TS5,TS9]
> >
> > Similarly, for the case of a STS-1-6c do we use:
> >       i)  (1,1), (2,1), (3,1), (4,1), (1,2) and (2,2)
> > [TS1,TS2,TS3,TS4,TS5,TS6] or
> >       ii) (1,1), (2,1), (1,2), (2,2), (1,3) and (2,3)
> > [TS1,TS2,TS5,TS6,TS9,TS10]
> >
> >
> > And which timeslots do we use for e.g. a STS-1-5c?
> >
> >
> > If this detail is not specified, interworking is not possible
> > unless we include
> > the list of timeslots as we do with virtual concatenation
> > (and as discussed for
> > flexible arbitrary concatenation).
> >
> >
> > Regards,
> >
> > Maarten
> >
 <<Card for Maarten Vissers>>