Re: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]

Greg Bernstein <> Tue, 10 March 2009 17:17 UTC

Delivery-date: Tue, 10 Mar 2009 17:19:12 +0000
Message-ID: <>
Date: Tue, 10 Mar 2009 10:17:48 -0700
From: Greg Bernstein <>
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
To: Adrian Farrel <>
CC: Giovanni Martinelli <>, Malcolm Betts <>, "O'Connor, Don" <>,
Subject: Re: Measuring impairments [Was: Updated Draft Liaiosn to Q6/15]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Whoops, sorry Adrian I mis-interpreted your statement: "There is no 
requirement to measure impairments."  To forever exclude the measurement 
of impairments. Rather than what it says, i.e., "that we don't make you 
measure impairments".

I particularly wanted to ask Q6 about G.697 as a guiding "framework" for 
measurements. It lists applications, classifies measurement types and 
gives a short list of some measurable parameters.

An aside: In one sense GMPLS already has some optical measurement 
capabilities via LMP. Also see Seno's new draft 
draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt that gives 
another data point for optical measurement applications.



Adrian Farrel wrote:
> I'm going to try to answer all of the comments about measuring 
> impairments in one email.
> I'm arguing all of this from an abstract point of view. I want to 
> "out" in advance of the meeting as much of opinion held in CCAMP. I do 
> not believe it is valuable to go into the meeting expressing what we 
> think may be Q6's view. Instead, we need to say what it is people in 
> CCAMP may want to do. Then we can get Q6 feedback on whether that is 
> practical and what the concerns are.
> So...
> The ability to measure optical impairments on an active path is 
> claimed by several vendors. I am not in a position to judge whether 
> they are successful or not.
> Giovanni reasonably asks "what exactly you mean by *ability to measure*?"
> We are proposing protocol extensions that allow nodes to distribute 
> information about optical impairments. It is not our business to 
> define from where this information is gathered. We can observe that 
> the information might be configured, might be measured during network 
> provisioning and held static, might be determined by a node applying 
> some algorithm to configured on pre-measured information, or might be 
> measured dynamically. So we can choose between:
> - optical impairments can be advertised, but cannot be updated
> - optical impairments can be advertised, and can be updated
> If we choose the first of these, it seems that we are shutting out 
> what some people want to be able to do. If we choose the latter, we 
> are not requiring anyone to update the information they advertise, but 
> we are allowing this to be done if a node chooses to do so.
> To answer Don specifically, I see no proposal in CCAMP about which 
> impairments could be measured or how they would be measured. But, to 
> turn this point around, I do not believe that CCAMP should say "you 
> must not measure an impairment". As Don says, this is outside our remit.
> Malcolm's suggestion doesn't cut it for me.
> By saying "We understand that Q6 currently has no requirement to 
> measure impairments after the transport equipment is deployed" we miss 
> the point. The point is not what Q6 requires or does not require, but 
> is what CCAMP requires.
> So I wonder what is wrong with the statement (in the context of 
> describing what CCAMP wants to do) that "There is no requirement to 
> measure impairments."
> Don objected specifically to...
>>    However, if an implementer chooses to measure impairments
>>    on their device, this should not be prohibited, and should be
>>    accommodated.
> How would it be if we defered the practicality of such measurements to 
> the ITU? We could then write...
>    However, if an implementer chooses to measure impairments
>    on their device, and this can be achieved within the mechanisms
>    and definitions defined by the ITU-T, then this should not be
>    prohibited by the CCAMP protocol mechanisms, and should be
>    accommodated within GMPLS.
> Cheers,
> Adrian

Dr Greg Bernstein, Grotto Networking (510) 573-2237