[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LBM comment
Hi Maarten and Greg:
Can you help me in understanding the following case?
LCAS is used for "hitless" increase or decrease of capacity
of an end-to-end pipe.
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.
"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
> 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:email@example.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
> 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
> 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
> 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
> NMS/ASON/GMPLS are in full control of the connections setup to support the
> virtual concatenated group.