Re: Virtual concatenation: a clarification on sequence numbers

Dimitri.Papadimitriou@alcatel.be Thu, 07 November 2002 08:46 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 07 Nov 2002 02:05:23 -0800
Message-ID: <3DCA285C.BAED0B7C@alcatel.be>
Date: Thu, 07 Nov 2002 09:46:20 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: Alcatel Bell - Optical NA (Antwerpen)
MIME-Version: 1.0
To: "Ong, Lyndon" <LyOng@ciena.com>
Cc: 'Heiles Juergen' <juergen.heiles@siemens.com>, "'gopi@india.tejasnetworks.com'" <gopi@india.tejasnetworks.com>, ccamp@ops.ietf.org, sjtrowbridge@lucent.com, "Bernstein, Greg" <GregB@ciena.com>, Anup@jasminenetworks.com, mvissers@lucent.com
Subject: Re: Virtual concatenation: a clarification on sequence numbers
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi,

i would rephrase your statement as "in case no flexibility
is delivered if it identifies the sequence number of the 
VC (used as convention) does it 1) remove any capability 
2) when provisioned and an event occurs such as a failure 
does it imply any processing", for 1) response is clear it
simply follows the capabilities of the data plane and for 2)
no more than what the data plane requires such that the
control keeps track of it, in conclusion you deliver the
capability to follow the usage of the data plane of the
corresponding components, it becomes a very good fallback
mechanism (see section 5.2 for more details). However, what 
i got with this discussion is that i have to refine a bit 
the flexible case (idea is to keep the same definition
and refer to the entry point of the selector, thus for
a locked selection the definition stays unchanged)

note for the community, we are discussing here the following
http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-04.txt

hope this clarifies,
- dimitri.


"Ong, Lyndon" wrote:
> 
> Hi Dimitri,
> 
> The signaling protocol should be able to identify the particular VC
> and also the virtual concatenation group it belongs to, but it's not
> still clear why it needs to identify the sequence number of the VC.
> One concern is that the sequence number may change in response to failure
> but there is no need for the signaling protocol to be aware of this
> for the remaining VCs, unless you tie the two together.
> 
> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, November 06, 2002 10:49 AM
> To: Ong, Lyndon
> Cc: 'Heiles Juergen'; 'gopi@india.tejasnetworks.com';
> ccamp@ops.ietf.org; sjtrowbridge@lucent.com; Bernstein, Greg;
> Anup@jasminenetworks.com; mvissers@lucent.com
> Subject: Re: Virtual concatenation: a clarification on sequence numbers
> 
> hi,
> 
> in any case you need a number, the reason why this
> has been proposed is to avoid yet another translation
> (mapping) table at the edges, these numbers must be
> unique in their applicability scope, thus there will
> always be a consistency check;
> 
> - dimitri.
> 
> "Ong, Lyndon" wrote:
> >
> > Hi Juergen,
> >
> > I was wondering about this, if the order of the VC-Ns is specified
> > twice (once by the automated path setup, and again by the
> > sequence number in the overhead) this could provide an additional
> > consistency check or it could be a source of error.  For automated
> > path setup, might it not be better to leave the
> > sequence number out of the GMPLS/ASON signaling and have it only in the
> > overhead?  Then there is no need for a consistency check.
> >
> > Thanks,
> >
> > Lyndon
> >
> > -----Original Message-----
> > From: Heiles Juergen [mailto:juergen.heiles@siemens.com]
> > Sent: Wednesday, November 06, 2002 8:41 AM
> > To: 'gopi@india.tejasnetworks.com'; ccamp@ops.ietf.org
> > Cc: sjtrowbridge@lucent.com; Bernstein, Greg; Anup@jasminenetworks.com;
> > mvissers@lucent.com
> > Subject: AW: Virtual concatenation: a clarification on sequence numbers
> >
> > Gopi,
> >
> > the sequence number always reflects the order of the VC-Ns within a
> virtual
> > concatenation and is never provisioned directly. In a SDH/SONET
> environment
> > with TMN provisioning and without LCAS the order is set by the TMN at the
> > source and sink. If the sink receives sequence numbers in the wrong order
> it
> > will alarm. With LCAS the order can change dynamical for example if one VC
> > fails and is removed from the group and later on added again. In case of
> > automatic path setup (GMPLS/ASON) this process has to define the order of
> > the VCs and as such the sequence numbers.
> >
> > Regards
> >
> > Juergen
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: gopi@india.tejasnetworks.com
> > > [mailto:gopi@india.tejasnetworks.com]
> > > Gesendet: Mittwoch, 6. November 2002 14:58
> > > An: ccamp@ops.ietf.org
> > > Cc: sjtrowbridge@lucent.com; GregB@ciena.com;
> > > Anup@jasminenetworks.com;
> > > mvissers@lucent.com
> > > Betreff: Virtual concatenation: a clarification on sequence numbers
> > >
> > >
> > > [ post by non-subscriber.  with the massive amount of spam,
> > > it is easy to
> > >   miss and therefore delete mis-posts.  so fix subscription
> > > addresses! ]
> > >
> > > hi..
> > >
> > > I was going through the thread
> > >         http://ops.ietf.org/lists/ccamp/ccamp.2001/threads.html#00295
> > >         subject: "concatenation extensions in sonet/sdh"
> > >
> > > I needed a small clarification on virtual concatenation sequencing
> > >
> > > Sequence number is sent by the transmitter and receiver checks for
> > > the sequence number to perform interleaving.
> > >
> > >   IS this sequence number "Provisioned"(on both terminating
> > > equipments) ?
> > >    OR
> > >   Is it automatically assigned by the transmitting equipment in some
> > >   sequence and the receiver synchronizes with the
> > > transmitters sequence number?
> > >
> > >
> > > I read the following relevant standards on virtual
> > > concatenation, but couldn't
> > > clearly understand how the receiver knows the sequencing of the
> > > individual links.
> > > + T1X1.5/2001-062(Synchronous Optical Network (SONET) - Basic
> > >     Description including Multiplex Structure, Rates and Formats,
> > >     put up on ftp.t1.org/..../1X150620.DOC)
> > > + G.707, G.783(virtual concatenation)
> > > + G.7042(LCAS)
> > >
> > > Thanx in advance
> > > Gopi
> > >
> > >
> > >
> > >
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361