Re: Updated Draft Liaiosn to Q6/15

Giovanni Martinelli <giomarti@cisco.com> Tue, 10 March 2009 09:18 UTC

Envelope-to: ccamp-data0@psg.com
Delivery-date: Tue, 10 Mar 2009 09:20:46 +0000
Message-ID: <49B6307A.7060405@cisco.com>
Date: Tue, 10 Mar 2009 10:18:50 +0100
From: Giovanni Martinelli <giomarti@cisco.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: "O'Connor, Don" <don.oconnor@us.fujitsu.com>
CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: Updated Draft Liaiosn to Q6/15
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7029; t=1236676731; x=1237540731; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20<giomarti@cisco.com> |Subject:=20Re=3A=20Updated=20Draft=20Liaiosn=20to=20Q6/15 |Sender:=20; bh=xHKl82VjDGooImym/MCNM+kVLYG8baIumkVzdm+axOE=; b=kIeorvMxLecTbQCWydG4mFViIP+oOZV+oi4UmWTCNU83JHYGqdYMJSwmwM ExW6NiQhCzB8msGgvojuMzxbgaJZl3b/sB5XnYIVpwNuOBnNWChje2iVKvqx 1huGJrNm71;
Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );

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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Adrian Farrel
> Sent: Monday, March 09, 2009 4: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 
>
>
>
>
>