Subject: RE: Optical IP activities

From: John Drake <[email-masked]>
Date: Tue, 21 Mar 2000 14:33:41 -0800

Peter,

I'm just going through my e-mail and I thought you note was very good.  

What we are proposing in draft-ceuppens-mpls-optical-00.txt is a different
approach to information hiding.  Rather than taking the overlay model
approach and hiding all of the optical specific stuff (a non-pejorative
term) inside a network cloud, we would hide the optical stuff within the
representation of an individual IP links.  This would still allow you to
support the overlay model, but it also allows you to support the peer model.

Thanks,

John
-----Original Message-----
From: Peter Ashwood-Smith [mailto:[email-masked]]
Sent: Friday, March 17, 2000 1:15 PM
To: [email-masked]
Subject: Re: Optical IP activities

> I believe the point was different. Whatever you do (a version of RSVP
> or CRLDP), whether you are essentially catering to a different set of
> requirements inside an optical network. In that regard, you may not
> only want to add "extensions", but may also find that you're either not
> using "standard" features or finding out some features to be
> inappropriate.

  What has happened is a general realization that no matter what we 
switch on, be it spacecial (fiber), time (TDM), frequency(lambda) or 
shim (statistical), the requirements on the signalling and routing
protocols are VERY similar with variations caused by certain physical
properties of each switching mechanism. These variations are probably 
not sufficient to warrant completely independent protocols. About the
most serious of these differences is the merge/non merge ability and
even that existed in the statistical (ATM) domain. As a result we are 
in the process of rationalizing and distilling out what the common 
properties are of all of these mechanisms and trying to build a common 
mechanism to deal with them all. We may or may not succeed however
since we rarely all agree on anything.

> Not quite. There are specific operational procedures inside an optical
> network and the question is how much of this must be characterised
> to the outside world. For example, should a router know about wavelength
> conversion limitations?

   Wavelength conversion limitations can be abstracted into constraints
we already deal with in existing constraint based routing systems like
ATM/PORS. For example, maximum reach is similar to maximum acceptable delay.
If we can find generic ways to express the constraints that optics imposes
a generic constraint based routing system should be able to deal with 
the problems. Besides, the constraints imposed by current optical 
technologies are being stretched every day. Reach, for example, gets 
longer and longer every year and may one day be a non issue.

   Even constraints like the desire to limit the number of wavelength
conversions to a minimum to reduce distortion/chirp, or even to reduce to
a single wavelength for equipement that cannot do a conversion, can
be expressed in abstract forms such as a label set, as in the draft-yanhe
or a suggested label as in the lang draft. Are these specific to the
optical domain? Probably, although one can see the immediate benefits
of a fixed shim label for a span of hops since it reduces read/write
operations and hence would improve forwarding performance in the
statistically multiplexed domain.

> >
> >   Abstraction in general is not good for traffice engineering. The
further
> > you get from knowing exactly how much bandwidth you have and where it is
> > the worse the job of computing, establishing and laying down routes you
> > can do. The more accurately the topology database reflects exactly the
> > resources you have to allocate, the more accurate a job you can do of
> > engineering your network.
> 
> The question is, whether in practice you would engineer paths across
> two different networks (IP and optical) or do the engineering (and
> capacity planning) in each network.

   I argue that given the choice you would pick one network since a
single level global/distributed optimal placement problem is "easier" to 
solve than a two level global/optimal placement problem. Actually I 
think the two level problem is unsolvable because it lacks exact 
data at the second level. A fact I'm sure many operators of existing
overlay networks will attest to.

   Cheers,

   Peter

---

From: Debanjan Saha <[email-masked]>
Date: Wed, 22 Mar 2000 10:58:11 -0600

John,

> support the overlay model, but it also allows you to support the peer model. 

I was going through the draft-ceuppens-mpls-optical-00.txt and could not
find any details regarding "we would hide the optical stuff within the
representation of an individual IP links". Where in the draft do you
deal 
with this issue.

Regards,
Debanjan

-- 
Debanjan Saha                         Phone: 732-923-4264          
Tellium Optical Systems               http://www.tellium.com