[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LBM comment
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:dbrungard@att.com]
> 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:sudheer@nayna.com]
> 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:mvissers@lucent.com]
> > 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
>
>