Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

[Maarten Vissers <[e-mail]>]

All,

Let me describe briefly the interactions in the transport plane that cause the
traffic interruption when LCAS is not used.

You get a traffic interruption if the sink doesn't know exactly at which point
in the
bitstream it has to start reading from the additional connection, or stop
reading from the to be removed connection.

A path termination/adaptation source function generates a fixed signal label.
When you set up a connection via GMPLS you first reserve the matrix connections
in the fabrics between source and sink path terminations in both directions
(Resv A => Z). Then in the Resv return direction (Z => A), the matrix
connections are committed (i.e. established). This implies that the at the
Z-endpoint the path source is connected to the connection and when the last
matrix connection is established, the path sink at A-endpoint receives a signal
with an equipped-specific signal label. Note that the last fabric may be located
in another equipment than the path endpoint.

At the moment the last matrix connection is closed (in both directions), also
the Z-end will receive a signal with eq-spec signal label.

It then takes about 3 frames to detect the new pointer value (which is
different). Once found, it then takes 0..2 frames to remove AIS insertion. Once
removed, it then takes 3..10 (typically 5) frames to clear the dUNEQ defect,
another 0..2
frames to remove AIS insertion, then some time to align to the multiframe and
get the delay compensating buffer adjusted correctly. 

If there are any bits inserted by the source during this period, you are loosing
bits. If the source is not transmitting bits over this connection during this
period, the sink may start reading from the connection before the source is
inserting bits. Again the transmission of the client signal is interrupted.

If you intent to change the equipment and SDH standards (sometimes this implies
a SW modification, sometimes it will be a HW modification) and force C2 in the
path termination source to 0x00 until the connection is setup, you can not
verify if the connection is setup while the path sink is still in signal fail
condition (dUNEQ is detected). If the hardware let you read the received TTI,
you may go around this verification phase issue.

But when you insert at the source client bits into the additional connection at
the time you change the 0x00 value in C2 to the eq-spec value, you will still
have the sink at the other end  detecting dUNEQ (takes 3..10 frames to clear),
inserting AIS (takes 0..2 frames to stop), and have its delay compensating
buffer being in a kind of free run out of service state until the AIS insertion
is stopped. After that moment, the process needs to frame align, detect the
phase difference, adjusts its buffer and then it is ready to support
transmission.

LCAS is designed under the knowledge that the connection is up and running, the
buffer process is fully aligned and when it is told at which time (i.e. bit
position) the bits should be read from the additional connection it will be able
to do so without loosing a single bit.

Hope this explains things a bit more.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Hello Maarten,
> 
> The fundamental question is still pending, why do we have a glitch with LBM
> and not with LCAS, please could you explain.
> 
> Thanks,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]]
> Sent: Monday, November 19, 2001 3:10 PM
> To: Mannie, Eric
> Cc: 'Zhi-Wei Lin'; Dimitri Papadimitriou
> Subject: Re: [T1X1.5] Re: LCAS and
> draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> 
> Eric,
> 
> "Mannie, Eric" wrote:
> >
> > Hello Maarten,
> >
> > > Turn this question around... why should we have a transport network for
> > which we
> > refuse to use some parts while the control plane implementation doesn't
> > support
> > it...
> >
> > (what is the "it" in the sentence ?)
> 
> "it" refers to functionality in the transport plane not supported by control
> plane based connection establishment.
> 
> >
> > Using the signal label transition cannot we expect less glitch than with
> > LCAS ?
> 
> With LCAS there is no glitch at all. Anything else will result in a glitch
> of
> most likely a few seconds.
> 
> >
> > I would like to add a section on GMPLS and LCAS interworking in the draft.
> > Originally, this is what we intended to do with Dimitri.
> 
> I do not like to call it interworking... GMPLS must be able to turn the
> final
> control over to LCAS when the user has requested hitless increase/decrease.
> See
> the in my reply to Dimitri on Friday at 17:29.
> 
> >
> > Anyway, it is better to give the possibility to each manufacturer to do
> > GMPLS LBM alone or GMPLS LBM with LCAS.
> >
> > > In my understanding, the control plane is an additional means to manage
> > connections in the transport network (i.e. in addition to the existing
> means
> > via
> > network management). It should as such not introduce restrictions into the
> > transport network... i.e. this alternative should add capabilities, not
> take
> > existing capabilities out...
> >
> > GMPLS LBM doesn't remove capabilities, but integrate these capabilities
> :-)
> > You know that I am not the type of guy that want to remove capabilities,
> but
> > rather I am the opposite :-)
> 
> In this case you did remove the hitless capability that comes with LCAS...
> As we
> are in a new week lets forget that you did propose this... :-)
> 
> >
> > Would you (and Lucent) survive if we add a section about GMPLS and LCAS
> > interworking to the draft, saying for instance that depending on the
> > strategic implementation choices, one manufacturer could decide to do one
> or
> > the other solution, or something like that ?
> 
> Lets not do this with this wording... the document needs a section
> describing
> the GMPLS scenarios with and without LCAS being present in the transport
> plane,
> and with and without the endpoints being within the network.
> 
> Regards,
> 
> Maarten
> 
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[e-mail]]
> > Sent: Monday, November 19, 2001 11:58 AM
> > To: Mannie, Eric
> > Cc: 'Zhi-Wei Lin'; Dimitri Papadimitriou
> > Subject: Re: [T1X1.5] Re: LCAS and
> > draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> >
> > Eric,
> >
> > > Why should we have a general signaling protocol (GMPLS) for which we
> > refuse
> > > to use some parts. When GMPLS is used, I don't see the interest of using
> > > another protocol to do a part of what GMPLS is doing. Moreover, this
> > causes
> > > interworking issues with GMPLS.
> >
> > Turn this question around... why should we have a transport network for
> > which we
> > refuse to use some parts while the control plane implementation doesn't
> > support
> > it...
> >
> > In my understanding, the control plane is an additional means to manage
> > connections in the transport network (i.e. in addition to the existing
> means
> > via
> > network management). It should as such not introduce restrictions into the
> > transport network... i.e. this alternative should add capabilities, not
> take
> > existing capabilities out...
> > If there would ever be an interworking issue (after introduction of a
> > control
> > plane) between transport plane and control plane, the control plane will
> be
> > adapted to remove the mistake inside of it.
> >
> > As indicated in one of my emails on Friday, ASON/GMPLS will have to
> support
> > connection bandwidth modification between virtual concatenated endpoints
> > which
> > do not support LCAS and which do support LCAS. ASON/GMPLS in a network
> with
> > virt
> > conc endpoints supporting LCAS will be less constrained than in a network
> > without LCAS support.
> >
> > Regards,
> >
> > Maarten
> >
> > "Mannie, Eric" wrote:
> > >
> > > Hi Zhi,
> > >
> > > Yes, and when LCAS is triggered it exchanges control message with the
> > remote
> > > end to synchronize with the addition/removal of VC(s)/SPE(s). This is
> > > signaling between the two ends.
> > >
> > > In the same way, GMPLS can be triggered by whatever wants the GMPLS LBM
> > > capability (algorithm, even a NMS, etc). In addition to the LCAS
> > > functionality, GMPLS will do the provisioning at each hop, etc.
> > >
> > > LCAS is a protocol (it is defined like that by the ITU-T/T1X1 see the
> > text).
> > > This protocol is also generic (it works for both G.709 and SDH/SONET
> like
> > > GMPLS). But LCAS is restricted to a very specific functionality only.
> This
> > > very specific functionality is just a part of GMPLS.
> > >
> > > Why should we have a general signaling protocol (GMPLS) for which we
> > refuse
> > > to use some parts. When GMPLS is used, I don't see the interest of using
> > > another protocol to do a part of what GMPLS is doing. Moreover, this
> > causes
> > > interworking issues with GMPLS.
> > >
> > > Kind regards,
> > >
> > > Eric