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

[Huub van Helvoort <hhelvoort@lucent.com>]

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.