RE: Updated Draft Liaiosn to Q6/15

"Malcolm Betts" <betts01@nortel.com> Tue, 10 March 2009 12:23 UTC

Envelope-to: ccamp-data0@psg.com
Delivery-date: Tue, 10 Mar 2009 12:25:39 +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: Updated Draft Liaiosn to Q6/15
Date: Tue, 10 Mar 2009 08:23:16 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5165D9841@zcarhxm2.corp.nortel.com>
Thread-Topic: Updated Draft Liaiosn to Q6/15
Thread-Index: AcmhAuZkMQCQg0yZQ8KK4l++oLD2bwAdb3eg
From: "Malcolm Betts" <betts01@nortel.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>

Adrian, good summary of the status. A few comments/suggestions to help
the debate:

Deployment scenario 3 "Concern for "basic" impairments" my recollection
is that we were considering network scenarios in which we could allocate
sufficient margin so that a "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.

Deployment scenario 4 "Concern for "advanced" impairments" again my
recollection is that in this scenario a full computation of the
accumulation of impairments including the impact on existing paths is
required.  This significantly increases the scope of information
required and the compute time.

One final concern:  
"With this in mind, CCAMP is looking to Q6/15 to work as a partner in
establishing:
- ....
- the rules by which such impairments are accumulated along a path
- ...."

This implies that we will standardize an aspect of path computation i.e.
the method of computing the accumulation of impairments.  If the path
computation is performed in a single PCE then it is only necessary to
standardize the collection of the impairments, if it is distributed
across multiple PCEs it may be preferable to only expose a "figure of
merit" for the portion of the path that has been computed vs.
standardization of the method of computation.  This should be discussed
with the experts from Q6.


Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: betts01@nortel.com

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Monday, March 09, 2009 5:50 PM
To: ccamp@ops.ietf.org
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-lambda-
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-framework-
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-impairmen
ts-02.txt

 "Information Model for Impaired Optical Path Validation"
http://www.ietf.org/internet-drafts/draft-bernstein-wson-impairment-info
-00.txt

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