[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LCAS and GMPLS



Hi, all

 I forward a nice comment from Mr. Huub van Helvoort.

 His comments indicates we need liason from ITU-T SG-15 regarding to this issue.

Best Regards
Wataru

Date: Wed, 27 Jul 2005 15:35:08 +0200
From: Huub van Helvoort <hhelvoort@chello.nl>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: "Wataru Imajuku <imajuku.wataru" <imajuku.wataru@lab.ntt.co.jp>
Subject: [Fwd: Re: LCAS and GMPLS]


Hello Wataru,

Thank you for your reply.
Would you be so kind to send the attached response also to
the ccamp list? In my name.

Kindest regards, Huub.
PS  My messages are not on the list:
    https://psg.com/lists/ccamp/ccamp.2005/maillist.html

-------- Original Message --------
Subject: Re: LCAS and GMPLS
Date: Wed, 27 Jul 2005 13:49:19 +0200
From: Huub van Helvoort <hhelvoort@chello.nl>
To: ccamp@ops.ietf.org
CC: Trevor Wilson <wilsont@nortel.com>, Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp>, Michael.Dueser@t-systems.com
References: <B03A52266C74544CA7C8CDB507AC5314018DA310@zharhxm1.corp.nortel.com>


Hello again,

I agree with what Trevor wrote:

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.

and:

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.

One point for the problem statement could be that in order to guarantee a hitless removal of one of the members in a VCG (decrease of bandwidth) there is a mandatory sequence: First remove member at ingress node, wait for confirm and only then remove path and member at egress node.

However, a solution was presented at the last ITU-T SG15/q11
meeting that removes this requirement.

Cheers, Huub.

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