RE: Updated Draft Liaiosn to Q6/15

["Malcolm Betts" <[e-mail]>]

I missed this in my first comments ;( I share the concern expressed by
Don.  

I suggest that we turn this into a question that we can debate with Q6.
e.g. replace
"- There is no requirement to measure impairments.
   - Many networks are engineered such that configured
      impairment values are enough information
   - Measuring can often produce ambiguous values
   - Equipment to perform measurement may be expensive
   However, if an implementer chooses to measure impairments
   on their device, this should not be prohibited, and should be
   accommodated."

with:

"We understand that Q6 currently has no requirement to measure
impairments
after the transport equipment is deployed.
   - Currently networks are engineered such that configured
      impairment values are enough information
Does Q6 foresee any value in the future for transport equipment
including the ability to measure the actual impairments on a path.  If
this is a possibility then it would be necessary to report these
impairment measurements in the same way as the configured impairments
are reported.



Malcolm Betts
Nortel Networks
Phone: [phone] (ESN 393)
email: [e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Giovanni Martinelli
Sent: Tuesday, March 10, 2009 5:19 AM
To: O'Connor, Don
Cc: Adrian Farrel; [e-mail]
Subject: Re: Updated Draft Liaiosn to Q6/15



O'Connor, Don wrote:
> Adrian
>
> Can you please remove this text
>
> " However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated."
>
> This should be determined by ITU not CCAMP. CCAMP cannot generate 
> standards that imply ROADM data plane functionality. If any optical 
> impairments are measured by ROADMs, ITU must first generate the 
> necessary standard
>   
Although I understand there could be some precedences  I would not the
remove the text.  In principle the RWA problem try to catch some data
plane constrains as well.

Cheers,
G

> Regards
>
> Don
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Adrian Farrel
> Sent: Monday, March 09, 2009 4:50 PM
> To: [e-mail]
> Subject: Updated Draft Liaiosn to Q6/15
>
> Hi,
>
> Had some comments off-list.
>
> New version with minor changes...
>
>  ===
>
>  Dear Peter,
>
> CCAMP experts are looking forward to our joint meeting with Q6/5 on 
> March 20th to discuss optical impairments and the control plane 
> operation of wavelength switched optical networks (WSONs).
>
> This liaison is to summarise the activity within CCAMP on this subject

> so far and to set out our objectives for this work.
>
> As you will be aware, the GMPLS control plane is designed to provide a

> dynamic control plane for a variety of switching technologies. Amongst

> these is the "lambda switch capable" data plane where devices are 
> OEOs, ROADMs, and photonic cross-connects (PXCs). In fact, lambda 
> switching was the technology that led to the development of MPLS from 
> the packet switching
>
> MPLS control plane.
>
> The IETF's CCAMP working group is the design authority for all 
> extensions to the GMPLS family of protocols.
>
> The original work on lambda switching networks within CCAMP recognised

> that there is a subset of optical networks in which it is possible to 
> disregard optical impairments and where the number of regeneration 
> points is high.
> In
> these environments, path computation can be performed on a 
> reachability graph, and lambda conversion can be performed as 
> necessary within the network.
>
> As PXCs were introduced into WSONs, it remained the case that optical 
> impairments could be disregarded by the control plane. Where 
> necessary, optimal impairment-aware paths could be computed off-line 
> and supplied to the control plane, leaving the control plane to handle

> establishment of connections and recovery after failure. Failure 
> recovery scenarios might
>
> lead to contention for wavelengths or suboptimal optical paths, but 
> these could be handled by crankback within the signaling protocol.
>
> More recent work on WSONs indicates that the proportion of pure 
> optical devices (ROADMs and PXCs) is increasing. This means that it is

> necessary to compute paths that offer end-to-end lambda continuity. 
> This problem (called the routing and wavelength assignment (RWA) 
> problem) must be solved, and may be compounded by devices with limited

> cross-connect capabilities (for example, with glass-through, a limited

> OEO matrix, or restricted port-to-port capabilities). In approaching 
> this problem it is convenient if there is a common identification 
> scheme for wavelengths across the whole
>
> network (previously, wavelength identification was a local matter 
> between the nodes at the ends of each link). To aid with this, the 
> CCAMP working
>
> group has developed
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambd
> a-
> labels-03.txt
>  that provides a protocol-independent encoding for wavelengths in a 
> way that is compliant with G.694. Further work on this problem space 
> can be seen in the following CCAMP documents:
>
> "Framework for GMPLS and PCE Control of Wavelength Switched Optical 
> Networks (WSON)"
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framewor
> k-
> 01.txt
>
> "Routing and Wavelength Assignment Information Model for Wavelength 
> Switched Optical Networks"
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-01.txt
>
> "Routing and Wavelength Assignment Information Encoding for Wavelength

> Switched Optical Networks"
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.
> txt
>
> 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. This gives rise to four distinct deployment
> scenarios:
>
> 1. No concern for impairments or lambda continuity.
>    (Original GMPLS)
> 2. No concern for impairments, but lambda continuity is
>     important. (The RWA problem)
> 3. Concern for "basic" impairments
> 4. Concern for "advanced" impairments
>
> In focusing on the third of these categories, CCAMP intends to base 
> its work on G.680 and related recommendations with the following 
> understanding:
> - G.680 (et al.) provides a complete list of simple constraints
> - 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.
> - There is no requirement to measure impairments.
>    - Many networks are engineered such that configured
>       impairment values are enough information
>    - Measuring can often produce ambiguous values
>    - Equipment to perform measurement may be expensive
>    However, if an implementer chooses to measure impairments
>    on their device, this should not be prohibited, and should be
>    accommodated.
>
>  With this in mind, CCAMP is looking to Q6/15 to work as a partner in
> establishing:
> - the complete list of impairments suitable for this type of network
>    - and the complete list of Recommendations to use as references
> - the rules by which such impairments are accumulated along a path
> - generic encodings and ranges of values for the impairments
>
>  For reference, some early work on impairment-aware GMPLS is listed 
> below.
> This work is not yet adopted as CCAMP work, but is likely to form the 
> basis of such work once we have discussed the way forward with Q6/15.
>
> "A Framework for the Control of Wavelength Switched Optical Networks
> (WSON)
> with Impairments"
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairm
> en
> ts-02.txt
>
>  "Information Model for Impaired Optical Path Validation"
> http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-in
> fo
> -00.txt
>
> Looking forward to a profitable meeting, Deborah Brungard and Adrian 
> Farrel CCAMP Working Group Co-Chairs
>
>
>
>
>