RE: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Huub,

>>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.

We called it a signaling protocol because it is not a transport protocol
(there is no payload), because it is not a management protocol (i.e. no SNMP
or TMN), because it is not a routing protocol (like OSPF, ISIS, BGP etc),
etc.

Obviously, a protocol that exchange control packets between two entities in
the purpose of modifying the bandwidth of a circuit, looks like a signaling
protocol. Note there are plenty of end-to-end signaling protocols that are
not hop-by-hop, like TCP, UDP, etc.

>>   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?

Those defined in GMPLS extensions for SDH/SONET (see the appropriate
drafts).

>>   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.

Sorry, this is exactly our point, LCAS doesn't does this. GMPLS is a
complete solution (self-consistent) that does also what the LCAS protocol is
not doing.

>>   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?

Sorry, I don't understand.

>>   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).

Yes, we are just saying that they are other ways of doing the same in the
transport plane than LCAS (i.e. alternatives that don't require a new
protocol in the POH) since we don't have to care about the control part that
is done by GMPLS.

>>   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.

Yes that matches our understanding. We were just speaking about a limitation
of GMPLS that we are solving, not more.

>>   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.

Yes, we never said the opposite. This is just to clarify the scope of GMPLS
LBM, nothing about LCAS.

>>   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.

It depends how the C2 transition is detected. I will remove that ASIC
paragraph anyway because it has nothing to do with the protocol.

>>   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?
 
We didn't. Adding a VC after a failure is the same as adding a VC.

How many frames do you wait with LCAS before having a valid control message
and CTRL field ?

Kind regards,

Eric