RE: LBM comment

[Heiles Juergen <[e-mail]>]

Deborah,

virtual concatenation with LCAS can also be used by non-GFP mapped clients like IP (via POS) and ATM.

Juergen

> -----Original Message-----
> From: Brungard, Deborah A, ALASO [mailto:[e-mail]]
> Sent: Thursday, March 21, 2002 4:26 PM
> To: Sudheer Dharanikota; Bernstein, Greg
> Cc: Maarten Vissers; ccamp
> Subject: RE: LBM comment
> 
> 
> Agree with Greg and Maarten.
> 
> Hopefully of help are some tutorials from the last T1X1 
> meeting on virtual conc and LCAS. I've given the links below. 
> Key is that LCAS is not about the addition/deletion of an 
> STS-x, this is handled by an EMS/NMS/control plane. LCAS is 
> about the use of the STS-x(s). It provides for the hitless 
> use of an STS-x by a client signal e.g. hitless resizing of 
> the bandwidth used by a client signal. It is based on the 
> premise that the STS-x is available. And, LCAS is only used 
> for client signals using virtual conc - it provides the 
> hitless resizing for the client mapping. The only client 
> signals defined for using Virtual conc/LCAS are the GFP 
> mapped clients: Ethernet, ESCON, Fiber Channel, FICON, etc.
> 
> Deborah
> 
> Links:
> LCAS:
> ftp://ftp.t1.org/T1X1/X1.5/2x150440.ppt
> Virtual concatenation:
> ftp://ftp.t1.org/T1X1/X1.5/2x150450.ppt
> GFP:
> ftp://ftp.t1.org/T1X1/X1.5/2x150460.ppt
> 
> 
> 
> 
> -----Original Message-----
> From: Sudheer Dharanikota [mailto:[e-mail]]
> Sent: Wednesday, March 20, 2002 9:15 PM
> To: Bernstein, Greg
> Cc: 'Maarten Vissers'; ccamp
> Subject: Re: LBM comment
> 
> 
> Hi Maarten and Greg:
> 
> Can you help me in understanding the following case?
> 
> Given:
> 
> LCAS is used for "hitless" increase or decrease of capacity
> of an end-to-end pipe.
> 
> Question:
> 
> How does the end nodes (of the pipe) know  whether a given
> increase of capacity is possible dynamically?
> 
> My view: I think this case can be addressed using NMS or
> using signaling protocol extensions. Using NMS we need
> to know the complete topology and "its current state". Using signaling
> protocol we can figure this information out either locally or 
> by polling.
> This is the case being called LBM.
> 
> Please comment.
> 
> - sudheer
> 
> 
> "Bernstein, Greg" wrote:
> 
> > Hi all, to reiterate what Maarten points out below: "LCAS 
> takes care of the
> > hitless addition/removal of this trail to/from the virtual 
> concatenated
> > group in service.".  Eric's statement concerning LCAS being between
> > PTE-to-PTE also applies to Virtual Concatenation in general.
> > Hence the SONET LTE layer (SDH MS termination) switches, 
> i.e., most of the
> > ADMs and XCs out there don't care that the signal is 
> virtually concatenated.
> > Hence all the current stuff in the SONET/SDH signaling 
> extensions concerning
> > virtual concatenation is just end system information and 
> not needed by the
> > network.
> > Is the LBM work really aimed at the virtual concatenated 
> case? If so it
> > seems unnecessary. Also instead of further complicating 
> connection signaling
> > couldn't we abstract things a bit to have some type of 
> grouping/association
> > of multiple (pt-to-pt) connections together rather than changing the
> > signaling protocol?
> >
> > Greg B.
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:[e-mail]]
> > Sent: Wednesday, March 20, 2002 8:29 AM
> > To: ccamp
> > Subject: LBM comment
> >
> > Not having had time earlier to read the LBM draft, I only 
> just came across
> > some
> > still VERYY INCORRECT text in 
> draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.
> >
> > >From section 3:
> >
> >    "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling 
> protocol enabling
> >    the bandwidth modification at end systems and setting up and
> >    releasing circuits provisioned and configured through Network
> >    Management Systems (NMS). However, LCAS doesn't apply to 
> setting up
> >    and releasing bandwidth at intermediate nodes. This 
> means that LCAS
> >    must be combined with an NMS system in order to offer a dynamic
> >    connection setup throughout the network. Therefore, the 
> advantage of
> >    using GMPLS is that it provides a complete integrated solution,
> >    allowing for a wide range of traffic parameter modifications."
> >
> > LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
> > combined
> > with either NMS or ASON or GMPLS, which latter 3 take care 
> of the set up or
> > release of a VC-n or ODUk trail. LCAS takes care of the hitless
> > addition/removal
> > of this trail to/from the virtual concatenated group in service.
> >
> > >From section 3:
> >
> >    "Using LCAS in parallel with GMPLS implies that GMPLS traffic
> >    parameters may be modified without the GMPLS control plane being
> >    aware of these modifications. However, GMPLS provides native
> >    capabilities to modify traffic parameters of an established LSP
> >    since MPLS-TE signalling was originally conceived to 
> allow traffic
> >    parameter (bandwidth) modification."
> >
> > Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
> > modified.
> > NMS/ASON/GMPLS are in full control of the connections setup 
> to support the
> > virtual concatenated group.
> >
> > Regards,
> >
> > Maarten
> 
>