RE: LBM comment

["Brungard, Deborah A, ALASO" <[e-mail]>]

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