RE: GMPLS dynamics vs. issues with optical amplifiers

["Richard Rabbat" <richard@us.fujitsu.com>]

Hi,
There are pros and cons to advertising optical information including lambda
availability and optical impairements.  GMPLS is not supposed to replace
advanced path computation tools. Actually, an entity such as the PCE would
be a perfect piece in the architecture of a lambda network as it is expected
to provide advanced computation capabilities beyond CSPF.
<begin shameless plug from my draft>
Actually, we've been looking at some interop scenarii where we are clearly
in need for standardization and mentioned one such scenario in 
http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels-01
.txt
<end>
I think it's time to do a proper analysis of what support already exists,
what is still needed and work on extensions (if needed) to support the new
generation of ROADM and PXC devices where interop is required.
A few vendors who build ROADMs and PXCs, as well as SPs deploying them have
expressed interest in this topic when we discussed the 1st version at CCAMP.
I think it's time to sit down and take a stab at it so we have an
interesting draft to discuss in Montreal.
Send me email if you have some cycles to spare on this topic.
Richard.
 

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk
> Sent: Monday, April 10, 2006 8:05 AM
> To: Filippo Cugini; Adrian Farrel; Marco Ruffini
> Cc: ccamp@ops.ietf.org
> Subject: RE: GMPLS dynamics vs. issues with optical amplifiers
> 
> 
> Hi all
> 
> About a year ago we started to collect requirements for towards this
> area in a draft. Our current thinking is that the optical/photonic
> networks will have fairly proprietary ways of dealing with the
> non-linear properties but that the interface to GMPLS can be 
> summarized
> as a fairly generic network interface with a simple metric and a
> blocking capability. We only got as far a the requirements.  The draft
> is in in need of a refresh I will try to do that shortly.  I have to
> contact some other people who were interested in the area. 
> 
> If you cannot find a copy of the draft I will send it to you. 
> 
> draft-ashwood-ccamp-gmpls-constraint-reqts-00
> 
> Regards,
> Don 
> 
>    
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org 
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini
> > 
> > 
> > Hi all,
> > 
> > IMO the issue will have to be faced soon. Transparent network 
> > elements such 
> > as ROADM and PXC are beginning to be deployed in optical 
> > transport networks. However, the current GMPLS does not 
> > provide any functionality to keep track 
> > of the signal quality degradation. Thus, transparent mesh 
> > networks must be 
> > statically designed, during the network planning, to 
> > guarantee that even the 
> > most impaired connection  (e.g., the longest path) is 
> > acceptable. Otherwise, 
> > because of the current GMPLS limits, connections can 
> > successfully be set up 
> > even if they do not comply with physical parameters 
> > constraints. However, the worst case design approach heavily 
> > limits the size of the 
> > transparent networks.
> > 
> >   Filippo
> > 
> > 
> > ----- Original Message ----- 
> > From: "Adrian Farrel"
> > >  [..]
> > > - There *might* be a future requirement to signal certain
> > >   constraints, but we would need to see the requirements clearly
> > >   stated.
> > > - There is probably a need to enhance the advertisement of
> > >   some key physical attributes of optical links and nodes in
> > >   the IGPs. At the moment, however, this information
> > >   appears to be gathered through inventory systems and
> > >   there has been very little consideration of this requirement.
> > 
> > 
> > 
> 
>