[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Hi Huub,
You wrote:
> [hvh] although GMPLS LBM is purely in the control plane, it still needs
> hardware to distribute the contiguous bitrate over the payload
> areas of the individual LSPs (and reconstruct it at the sink).
> Virtual concatenation as it is defined now (without LCAS!) cannot
> be changed in size without interrupting the traffic. The make-before-
> break concept you propose requires also new ASICS to be developped.
This is really the challenge of far can we go in the performance of the
proposed mechanism without changing the ASIC from the one providing VC.
Today we are at an "engineering" level trying to refine the mechanism
(the
one lengthy described by Eric). As said on Friday (by Eric and myself)
any improvement or input to help for this purpose is highly appreciated.
Thanks,
- dimitri.
Huub van Helvoort wrote:
>
> Eric,
>
> After reading the draft-mannie-ccamp-gmpls-lbm-tdm-00.txt I have some
> questions see [hvh] between the text:
>
> >3. GMPLS LBM versus LCAS
> >
> > LCAS causes internetworking issues with GMPLS. Having two
> > signaling protocols running in parallel to control the same LSP is
> > not an ideal case.
>
> [hvh] why do you call LCAS a signaling protocol? it is a scheme to keep
> the source and sink of a virtual concatenated signal synchronised
> regarding the payload offered by the individual members of the
> virtual concatenated group, how the payload is transported through
> the network from source to sink, i.e. the path, is up to the
> control plane.
>
> > Using LCAS in parallel with GMPLS implies that
> > GMPLS traffic parameters may be modified without the GMPLS control
> > plane being aware of these modifications.
>
> [hvh] which traffic parameters do you mean? it cannot be the number of members
> in the virtual concatenated group, because the control plane tells LCAS
> how many there are. If a member fails, this is indicated to the control
> plane, but the member remains in the group even though its payload is
> not used any more. If the failure cannot be repaired the control plane
> has to replace the failed member by a remove-add sequence.
>
> > However, GMPLS provides
> > natively capabilities to modify traffic parameters of an
> > established LSP.
>
> [hvh] please tell me where you read in G.7042 that LCAS does this.
>
> > Indeed, the MPLS signaling was originally
> > conceived to allow traffic parameter (bandwidth) modification.
> >
> > LCAS is a signaling protocol restricted to the bandwidth
> > modification at end systems. It doesn't allow setting up and
> > releasing circuits dynamically, and doesn't allow setting up and
> > releasing bandwidth in intermediate nodes.
>
> [hvh] Now I am confused, isn't this exactly what you claim LCAS does do
> in the first paragraph?
>
> > The advantage of using
> > GMPLS is that it provides a complete integrated solution, allowing
> > for a wide range of traffic parameter modifications.
>
> [hvh] LCAS provides flexibility to existing virtual concatenated signals
> and relieves the control plane of the task of synchronising source
> and sink side use of available payload of a virtual concatenated
> signal (similar to pointer processing).
>
> > Using multiple LSPs to support a single circuit (optional) has the
> > drawback of requiring more signaling but this seems to be the most
> > appropriate way to operate within the context of a global control
> > plane. It provides the advantage that each independent LSP can be
> > protected/restored independently.
>
> [hvh] the transport of a virtual concatenated signal by using multiple
> signals, is a characteristic of virtual concatenation, for
> each signal a path through the network has to be set up by the
> control plane irrespective of LBM or LCAS.
> Virtual concatenation (with/without LCAS) allows any independent
> protection scheme to be applied to the individual members.
>
> > Note that GMPLS LBM can be first
> > used to modify the bandwidth of a single unique LSP (circuit),
> > without any LSP combination.
>
> [hvh] here is no difference with LCAS, this also allows a virtual
> concatenated signal with a single member.
>
> > One drawback of LCAS is that it requires changing the transport
> > plane since new overhead bytes are used. In consequence, new ASICs
> > must be used at both termination ends. On the contrary, GMPLS LBM
> > is done purely in the control plane. It does not require any new
> > ASICs and is backward compatible with the existing hardware.
>
> [hvh] although GMPLS LBM is purely in the control plane, it still needs
> hardware to distribute the contiguous bitrate over the payload
> areas of the individual LSPs (and reconstruct it at the sink).
> Virtual concatenation as it is defined now (without LCAS!) cannot
> be changed in size without interrupting the traffic. The make-before-
> break concept you propose requires also new ASICS to be developped.
>
> > This specification defines how to perform bandwidth modification
> > using the GMPLS signaling. The final result will be almost similar
> > than the one achieved using LCAS, with the advantage of being an
> > integrated solution that doesn't require adaptation of the
> > transport plane.
>
> [hvh] why did you totally ignore the solution LCAS provides to survive
> a failure in the network affecting one member, decreasing the
> available payload (by the members contribution to the total
> payload) and hitless adding th payload after the failure clears?
>
> >4. GMPLS LBM Procedures Using a Parallel Circuit
> >
> > This section describes how to modify the bandwidth of a circuit by
> > establishing a new completely bandwidth disjoint circuit and
> > moving the traffic to that new circuit by doing a switchover. This
> > procedure can be done manually or automatically. It uses a
> > simplified version of the make-before-break concept.
>
> [hvh] how do you propose to synchronise source and sink about the point
> in time to switch from one to the other without losing data?
>
> In the make-before-break scheme, when increasing the payload even by
> one member in a virtual concatenated group there have to be X+1 paths
> available before the switch can be performed. LCAS only requires the
> paths for the members to be added, so LCAS allows a link to be used
> for 100%.
> When decreasing the payload even by one member in the virtual concatenated
> group there have to be X-1 paths available before the switch can be
> performed. LCAS only releases the member without requiring any additional
> path first.
>
> Kind regards, vriendelijke groeten,
>
> Huub.
> --
> ------------------------------------------------------------------------
> | Huub van Helvoort | Lucent Technologies | PO Box 18 |
> | TEL: +31 35 687 4393 | ONG Systems Engineer | 1270 AA Huizen |
> | FAX: +31 35 687 5964 | mailto:hhelvoort@lucent.com | The Netherlands |
> ------------------------------------------------------------------------
> Always remember that you are unique... Just like everyone else.
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard