RE: Re-Updated Draft Liaison to Q6/15

"Malcolm Betts" <> Wed, 11 March 2009 12:49 UTC

Delivery-date: Wed, 11 Mar 2009 12:52:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Re-Updated Draft Liaison to Q6/15
Date: Wed, 11 Mar 2009 08:49:16 -0400
Message-ID: <>
Thread-Topic: Re-Updated Draft Liaison to Q6/15
Thread-Index: AcmhvBwFi3BA2QIGTBKyIp3teN4M9wACQHGAACAygPA=
From: "Malcolm Betts" <>
To: "O'Connor, Don" <>, "Adrian Farrel" <>, <>

Adrian, all

Looking at the comments from Don and Dan I think we should take a step
back and think about the requirements that the protocol extensions are
intended to address:

I think we can all agree that we must be able to report link impairments
and the encoding we use should accommodate the parameters currently
defined by Q6 and should be extensible to accommodate any parameters
that are defined at a later date.

Now to the more contentious issues:

- How frequently do we expect the impairment parameters to change, is it
in the order of mSec, Seconds, minutes, hours, days.  I suggest that
once it is beyond seconds the actual frequency becomes a "don't care".

- Does the protocol need to activate/deactivate measurements on an in
service link.  If so what types of parameters would need to be specified
for these measurements.

My assumption is that if we define an extensible method for reporting
link impairment parameters then we can use the same message to report
any link impairments independent of how they are provided (provisioned,
measured at installation time, measured in service...).

I suggest that we phrase the liaison to get input from Q6 to help us
define the requirements for these last two points. 

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)

-----Original Message-----
From: O'Connor, Don [] 
Sent: Tuesday, March 10, 2009 5:45 PM
To: Adrian Farrel; Betts, Malcolm (CAR:X632);
Subject: RE: Re-Updated Draft Liaison to Q6/15

Adrian, all

I agreed with

" we should phrase the liaison to stimulate a discussion with the
experts in Q6 on the value of making measurements on active optical

In returning to your draft liaison I do not agree with

" In focusing on the third of these categories, CCAMP intends to base
its work on G.680 and related recommendations with the following

We have not yet reached this level of agreement in CCAMP as no ID
pertinent to WSON with optical impairments has progressed beyond
individual contribution

I do not agree with the following interpretation of G.680

" Where G.680 refers to "single vendor" domains, it does not
   mean single manufacturer, but rather "single system integrator".
   That is, the equipment is not "plug and play", but has been
   tested to interoperate and the network has been planned."

I think the following sentence is misleading in the context alternative
3) "impairment estimation"

" There is no requirement to measure impairments."

Even for estimation, it may be necessary for the ROADM to make some
measurements. It will be necessary for ITU SG 15 Q6 to define the
details of any estimation scheme including any associated measurements. 

So my proposal is to truncate all the text after the definition of what
CCAMP currently believes are the four alternatives. But add some
additional text on discussion of WSON with optical impairments with ITU
SG 15 Q6. I suggest the following

" CCAMP participants have further identified cases where they believe it
would be helpful to consider optical impairments during the control
plane operation of a WSON. We also believe that this gives rise to four
distinct deployment scenarios:

1. No concern for impairments or lambda continuity
   because there is sufficient margin in all impairments.
   (Original GMPLS)
2. No concern for impairments (again because there is
    sufficient margin), but lambda continuity is important.
   (The RWA problem)
3. Networks in which it is necessary to consider impairments,
   but there is sufficient margin such that approximate
   impairment estimation (using "simple" computation of the
   accumulation) could be used and still have a high
   probability that the optical path would be viable and would
   not perturb any existing paths.
4. Networks in which detailed impairment validation is
   necessary to perform a full computation of the accumulation
   of impairments including the impact on existing paths.

It has also been suggested in the course of our discussions that G.680
can possibly to applied to address some of the requirements of 3) and
4). We would like to initiate discussions with Q6 on routing and
wavelength assignment with optical impairments and the associated
control plane support. We would like to apply existing ITU standards
such as G.680, but also understand that if any new standard ROADM
functionality is needed that such standardization would fall within the
scope of ITU SG 15 Q6"

For reference, some early work on impairment-aware GMPLS is listed
below. This work is not yet adopted as CCAMP work.

"A Framework for the Control of Wavelength Switched Optical Networks
(WSON) with Impairments"

"Information Model for Impaired Optical Path Validation"

Looking forward to a profitable meeting, Deborah Brungard and Adrian
Farrel CCAMP Working Group Co-Chairs"



-----Original Message-----
From: [] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 10, 2009 3:07 PM
To: Malcolm Betts;
Subject: Re: Re-Updated Draft Liaison to Q6/15

Hi Malcolm,

> Adrian, I don't like either paragraph....

Consensus is a slippery beast.

> The point I was attempting to raise, and I think Enrique made a 
> similar point, is that we should phrase the liaison to stimulate a 
> discussion with the experts in Q6 on the value of making measurements 
> on active optical paths.

I don't object to this discussion, or any other discussion.

Maybe we need to separate measuring impairments on the idle components
of an OLS while other components may or may not be active (which is what
I thought people wanted to do), and measuring impairments on active
components (which I had not heard people suggesting they would do).