RE: LCAS and GMPLS

["Trevor Wilson" <wilsont@nortel.com>]

Hi,

VCAT (and LCAS) functionality is required ONLY at the terminating TDM
NEs of a Virtually Concatenated signal. As long as the 'intermediate
NEs', through which the individual VC-ns are transported, have the
capacity to carry those VC-ns then the SONET/SDH network will provide
the necessary connection. For any given VCAT connection, the
intermediate NEs do not need to be VCAT/LCAS capable. Therefore I do not
understand why, in the 'problem statement of
'draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt', each TDM node should
advertise its VCAT/LCAS capabilities. When the connection is being
provisioned, it is up to the SDH/SONET NMS to determine whether or not
the network (and it's NEs) are capable of a VCAT/LCAS operation.
In the TDM network, label switching is not performed, except perhaps at
the edge of the network where the client signal is encapsulated into the
transport technology. Therefore I believe that the routes for the
individual VC-ns of a virtually concatenated group (VCG) are of no
consequence to the client signal, and the VCG can be looked upon as a
single LSP between the TDM ingress node and the TDM egress node.

Michael:

Below you state that LCAS is Bi-directional.
For LCAS to operate it needs at least one member in both directions; but
essentially the LCAS operation is uni-directional in nature. If
bandwidth adjustment is required in both directions it is necessary to
initiate these separately.

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel. 
>


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Wataru Imajuku
Sent: 27 July 2005 05:28
To: Michael.Dueser@t-systems.com; ccamp@ops.ietf.org
Subject: Re: LCAS and GMPLS


Hi, Mr. Dueser and all

  Thank you for your comment.

  As you pointed out, the GFP/LCAS/VCAT functionality is temination
capability.
  But, it can easily migrate with non-GFP/LCAS/VCAT TDM network,

  The one of ID's requirements includes the extension for the routing
protocol in order to advertise such termination capability in each node.
  I believe this routing extension helps smooth migration amongst
GFP/LCAS/VCAT capable and non capable networks.

  In the -00.txt version, the ID suggests the extension to
  Interface Switching Capability Descriptor (ISCD) as a temporal
suggestion.
  Because, I understand that the meaning of interface switching
capability 
descriptor
  includes both transit capability and termination capability of LSPs.

  However, the explicit addition of termination capability to the ISCD
may 
be one of choice,
considering the more generic node architeture as discussed in Dimitri's 
MRN-extensions draft.

  I hope the discussion in Paris meeting also for above issue .

Best Regards,
Wataru

Hi,

>some comments re I-D draft-imajuku-ccamp-gmpls-vcat-lagr-req-00:
>
>- LCAS was not intended for grouping of VC-X-yvs, but for 
>synchronization
>of the VC-X which is added or dropped. And it's bi-directional.
>- Only the terminating nodes need to have the full GFP+LCAS+VCAT
functionality.
>- You need to be careful when using the verbs may, shoul and must - are

>they conform to IETF convention?
>
>I believe in general this is an important I-D also wrt to the ITU-T
>liaison and for implementation! I believe we can also discuss details 
>during the IETF next week.
>
>Michael Dueser

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541