Subject: Re: [CCAMP] WSON Impairment scenarios -- control plane perspective...

From: Greg Bernstein <[email-masked]>
Date: Fri, 07 Aug 2009 09:53:47 -0700

Hi Giovanni, I'm not sure about the terminology either. At IETF we tent 
use the term opaque, at ITU-T SG15 Q6 they use the term "black links". 
Whatever we end up using we need to define it clearly.  See comments on 
your comments below.

Cheers

Greg

Giovanni Martinelli wrote:
> Hi Greg,
>
> thx for the text, very useful. Few initial comments hoping discussion 
> will continue with other contribution as well.
>
> first a terminology consideration about opaque, Don't have a better 
> suggestion right now but not sure the term usage.  "Opaque"  is the 
> path validation procedure (if any) respect to the control plane?
>
> plus few others comments inline
>
>
>
> Greg Bernstein wrote:
>> Hi folks, there seemed to be some questions about where we could get 
>> started with WSON impairments. On reviewing the Impairment Framework 
>> draft, it seems like we've got a lot of bases covered but we aren't 
>> explicit about one could get started dealing with optical impairments.
>>
>> Below is a short analysis with somewhat "loose" language. Some of 
>> this could potentially be useful in a liaison to ITU-T Q6.
>>
>> Comments welcome.
>>
>> Greg B.
>>
>>
>>   *Impairment Estimation Categories and the Control Plane*
>>
>>
>>     Opaque WSON with respect to Impairments
>>
>> In this case we are given a list of qualified paths between a desired 
>> source and destination of a connection. These paths may come with 
>> wavelength restrictions due to impairments (not related to wavelength 
>> availability in RWA process).
>>
>> We do not know anything about how these viable paths are computed. We 
>> don't know and shouldn't care if the impairments are linear or 
>> non-linear.
>>
>> We are assured that if we select one of these paths and assign a 
>> wavelength to it then the establishment of this connection will not 
>> impact previously established connections in the network.
>> Example usage: a single vendor supplies WDM line systems and ROADMs. 
>> We wish to use a GMPLS control plane and perhaps PCE based 
>> optimization but not all paths through the network are viable due to 
>> impairments.
>>
>> ITU-T Q6 implications: My guess it that the Q6 folks would not care 
>> about this case since this doesn't really call for standardization of 
>> impairment parameters or procedures.
>>
>> CCAMP implications: This seems like a very practical case for the 
>> control plane. We would only want to standardize the way in which we 
>> obtain the list of qualified paths. */No impairment information model 
>> is needed here/*. An architecture reflecting this option is already 
>> in the Impairment Framework draft.
>>
> Agree with all the above. The only point is that probably the fact of 
> having a set of qualified path does not preclude the need of having 
> impairment considerations as well (sort of mixed solutions).
>
> I  mean, your text above does not preclude it but I want just to make 
> the point clear.
--> I'm not quite sure of your "mixed" scenario here.  How would a 
"mixed scenario" work?
>
>
>>     Partially Opaque WSON
>>
>> In this case the impairment behavior of certain elements of the WSON 
>> can be suitably modeled via standardized techniques, e.g., G.680 
>> while other parts of the WSON are not. The entity responsible for 
>> these other parts of the WSON imports the characteristics of these 
>> "open" elements and uses them as part of a viable path computation 
>> process, the details of which are opaque to the control plane.
>>
>> We are assured that if we select one of these paths and assign a 
>> wavelength to it then the establishment of this connection will not 
>> impact previously established connections in the network.
>>
> I would apply here the same as below "this is beyond a purview of a 
> standard organization to specify".
-->  There are some aspects of this scenario that are amenable to 
standards other are not. There is can be an info model for the portion 
modeled by standards, along with a standard way of conveying that 
information to the "opaque system" that performs the computations.
>
>> Example usage: The characteristics of the WDM line systems are not 
>> specified, but well characterized ROADMs are used in the WSON. The 
>> WDM line system vendor uses these characteristics in its 
>> internal/proprietary viable path computations.
>>
>> Q6 and CCAMP implications: here we would be using a standardize 
>> information model for the "open" WSON network elements. How the other 
>> "opaque" network elements are characterized and how viable path 
>> computation is carried out is out of scope of either SDO. Such an 
>> approach takes advantage of standardized impairment models where it can.
>>
> just to clarify "standardized impairment model", are you referring to 
> G.680 or something else?
--> Yes, G.680 and related specifications. Currently G.680 models ROADMs 
but not line systems so this scenario is compatible with G.680 as it 
stands today.
>
>
>> Implications for CCAMP would be an impairment information model and 
>> an interface for requesting/receiving qualified paths. An 
>> architecture that can support this case is already contained in the 
>> WSON impairment framework draft.
>>
>>
>>     Linearly Approximated Open WSON Impairment Model
>>
>> In this case the impairment aspects of the WSON can be well 
>> approximated by standardized (or to be standardized) "linear" models 
>> such as those found in G.680. From these models the viability of 
>> paths can be evaluated.
>>
>> We are assured that if we select one of these paths and assign a 
>> wavelength to it then the establishment of this connection will not 
>> impact previously established connections in the network.
>> Implications for Q6: Current impairment models such as recent version 
>> of G.680 do not include models for WDM line systems.
>>
> why this? Isn't a line system a  de-generated case of an ROADM  (1 
> ingress, 1  egress)?
---> Probably better directed at Q6 than me. I pretty much agree with 
you. I just know what the current version of G.680 says :-(    .
>
> thx
> G
>
>> Implications for CCAMP: An impairment information model is needed. 
>> Distributed impairment validation (via signaling) could be possible.
>>
>> General comments: it would seem to be the responsibility of the WSON 
>> network designer to insure that the network is operating in a 
>> "region" where these linear approximations for impairments are valid. 
>> This seems beyond the purview of a standards organization to specify.
>>
>> An architecture to accommodate this case is contained in the WSON 
>> impairment framework draft.
>>
>>
>> -- 
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>   
>

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

---

From: Giovanni Martinelli <[email-masked]>
Date: Wed, 12 Aug 2009 15:19:08 +0200

Hi,

thx for your reply

Greg Bernstein wrote:
> Whatever we end up using we need to define it clearly. 
>
ok, let see if anyone has comments

> See comments on
Well in principle yes could work: you have some path fully designed off 
line and while network evolve you may need to add other lightpath(s).
How to deal with this I suppose is a network operator choice and I would 
not preclude it.

> but not line systems so this scenario is compatible with G.680 as it
ok
> you. I just know what the current version of G.680 says :-(    .
fair enough, but yes probably worth clarify it with Q6

Cheers
G