Subject: RE: Comments on draft-ip-optical-framework-00.txt

From: John Drake <[email-masked]>
Date: Tue, 21 Mar 2000 15:42:05 -0800

In the Awduche draft, what is termed an OXC is actually a composite node
consisting of of an optical or photonic cross-connect surrounded by DWDM
systems.  This is a very likely deployment scenario and this composite node
does have wavelength conversion acability.

Thanks,

John
-----Original Message-----
From: Lee Thomas [mailto:[email-masked]]
Sent: Tuesday, March 21, 2000 3:21 PM
To: 'Khaled Elsayed'
Cc: [email-masked]
Subject: RE: Comments on draft-ip-optical-framework-00.txt

Peter Ashwood-Smith wrote:
>   You may waste enormous amounts of bandwidth if you cannot do
> wavelength conversion. Convert the question to the ATM domain and
> imagine how an ATM network would operate if you had to use the
> same VCC from end to end. Basically, if you do not have the ability
> to change "labels" then you need one label for EVERY unique path
> through the network. Given that the number of paths through a network
> grows what .. N factorial? You run out of labels very quickly. This is
> especially true with DWDM equipement which may only support 50-100
"labels".
> This means that a tiny  network would exhaust all the labels/paths
> AND you have many links that you can only use a small percentage of
> the available "labels" ie bandwidth. So its a very unsatisfactory
> solution. Also, to do a good job of it, you need a global view of
> each path and label it will use.
>

I am not questioning the usefulness of wavelength conversion. It
is definitely a good mechansim. (Although I have seen some
research work that claims that wavelenght conversion may not be
worthwhile in some scenarios).

Khaled,

Could you provide links to some of this research or describe some scenarios
where wavelength conversion may not be worthwhile?

Thanks,

Lee

---

From: Jonathan Lang <[email-masked]>
Date: Tue, 21 Mar 2000 16:04:37 -0800

Lee,
  There may be situations where if you have say 80 wavelengths, for
performance reasons you may want to restrict the wavelength conversion to
bands of say 8 wavelengths, where full-wavelength conversion is allowed only
within the 8 wavelengths of a band (as opposed to over all 80 wavelengths).
Furthermore, by adding flexibility to the routing algorithms, you can obtain
performance gains close to those obtained by increasing the degree of
wavelength translation.

  We currently have a paper analyzing the above under review at the IEEE/ATM
Transactions on Networking, however, parts of it can be found in my thesis.
The thesis can be found online at
http://spetses.ece.ucsb.edu/~jonathan/thesis.html, but the chapter related
to this issue is Chapter 4 (also can be found at the above http site).

Regards,
Jonathan

-----Original Message-----
From: Lee Thomas [mailto:[email-masked]]
Sent: Tuesday, March 21, 2000 3:21 PM
To: 'Khaled Elsayed'
Cc: [email-masked]
Subject: RE: Comments on draft-ip-optical-framework-00.txt

"labels".

Khaled,

Thanks,

Lee

---

From: Markus Buchhorn <[email-masked]>
Date: Wed, 22 Mar 2000 11:37:48 +1100

>>My point is a
>>connection of 2.48 Gbps is not likely to be a random event or an
>>ATM-like SVC. 
>
>Agreed - atleast not for some time (2 years? 5??)

I'm not sure that I'd agree it would be out that far. Think of things like
fail-over circuits (back-hoe avoidance algorithms...), bandwidth balancing
in the core of the networks, etc. In these cases a 2Gb/s (or whatever)
circuit could be required with a quick set up, and eventual tear-down -
like an ATM SVC. No reason to leave a dim lambda sitting round for that...

Cheers,
	Markus

>>Of course
>>wavelength conversion can help build a better-utilized network,
>>no question about that.
>
>Agreed again. Service providers will ofcourse do their own
>cost-benefit to see if it makes sense.
>
>-jagan.
>
>>
>>Khaled
>> 
>>> I suspect this is a provisioning issue. Currently it is a nightmare
>>> to provision for the expanding needs of customers.. with advanced
>>> intelligent optical systems, fatter pipes can be provisioned as easy
>>> as ordering a pizza? I will however humbly defer to those who know
>>> more about the need for dynamic optical path setup and traffic
>>> mgmt.
>>>
>>
>>
>>
>
>Jagannath Shantigram
>Photonex Corporation
>
>
Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: [email-masked], snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 23 Mar 2000 13:29:16 -0500

Yangguang,

I don't think any product that claims to do purely optical cross-connecting
supports wavelength conversion. The OEO based devices might do so.

-Vishal

On Thursday, March 23, 2000 10:32 AM, [email-masked] [SMTP:[email-masked]] wrote:
> 
> There have been many discussions about wavelength conversion. And we all agree
> it is good. Can anyone tell me which OXC product (commercially announced)
> doesn't support wavelength conversion?
> 
> Yangguang

---

From: John Drake <[email-masked]>
Date: Thu, 23 Mar 2000 13:53:50 -0800

Krishna,

A few points:

1)  In the peer model, the routers are not necessarily aware of the complete
details of every optical link;  if there is information that they don't
need, it can be filtered out on a link by link basis by the PXCs.

2)  In the Overlay model, the PXC is computing the routes, so in your
terminology it is fat, agile, and smart.  There is also nothing that
precludes an optical UNI in this model.

3)  Why the open model is called open is beyond me, since by definition the
control plane in each of the clouds is proprietary.  I think a better way of
characterizing the open model is that it is just a special case of either
the peer or the overlay model, in which the vendor does not want to have a
standards based control plane between its switches.  I.e., it
implements the standards based control plane at the edges of its network.
What you're calling an optical NNI is what I would call MPL(ambda)S.

Thanks,

John
-----Original Message-----
From: Krishna Bala [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 11:59 AM
To: [email-masked]; Jagan Shantigram
Cc: Khaled Elsayed; [email-masked]; [email-masked]
Subject: RE: Comments on draft-ip-optical-framework-00.txt 

Jagan,
There are several architectural models for IP over Optical Networks that
are emerging:

1. Peer Model
In this model the IP router is entirely aware of the details on the
underlying
optical network (topology information, wavelength and port usage and lamda
assignment).
It is able to control and manage entire end to end paths. In this model the
OXC is "agile but fat & dumb".
2. Overlay Model
The optical layer is "fat & dumb". The lamda connections between the IP
routers behave as if they were dedicated fibers between them. The IP routes
provision logical optical circuits over a fixed or at best a quasi-fixed
optical
layer.
3. Open Model
In this scenario the optical layer comprises of several "vendor/network
operator clouds"
that have well defined interfaces. For example, an Optical UNI can be used
to
interconnect the IP router to the OXC and the Optical NNI can be used to
connect
two optical network domains together. Here the optical layer is "fat, smart
and agile".

It is unclear at this time which of these models will prevail.

Krishna Bala
Tellium

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Curtis
> Villamizar
> Sent: Thursday, March 23, 2000 1:55 PM
> To: Jagan Shantigram
> Cc: [email-masked]; Khaled Elsayed; [email-masked];
> [email-masked]
> Subject: Re: Comments on draft-ip-optical-framework-00.txt
>
>
>
> In message <[email-masked]>, Jagan
> Shantigram wr
> ites:
> > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote:
> > >
> > >In message <[email-masked]>, Khaled Elsayed writes:
> > >>
> > >>
> > >> Hello Jagan,
> > >>
> > >> > When we do not have lambda conversion however, this problem cannot
> > >> > be solved optimally.. it is akin to the graph coloring
> > >> > problem - which ofcourse has heuristics that can get us to
> > >> > a factor (?) of the optimal solution. So, connections may
> > >> > be blocked even though there is capacity on the fiber to
> > >> > support it, just because the wavelength is already used up.
> > >> >
> > >>
> > >> Connections can be blocked when?? At service provisioning time or
> > >> at the time the connection is requested?? My point is a
> > >> ATM-like SVC. If a customer would require such huge bandwidth, it
> > >> would need that BW to go through or it would better look for
> > >> another carrier that will provide a TDM/leased line?? Of course
> > >The exception to the rule that "a connection of 2.48 Gbps is not
> > >likely to be a random event" is where a very major event, possilble
> > >external to one's own network results in a shift in traffic patterns
> > >that is significant enough to require that additional lambdas be added
> > >to existing paths.
> > >
> > >The real world example in the ISP world is a failure of a peering
> > >point of some sort, a provider interconnect, a NAP or NAP connectivity
> > >of some party.  Since all major ISPs are connected to each other at
> > >more than one geographically diverse peering point, the traffic will
> > >still flow, but the path will have changed.
> > >
> > >This may mean that a path that previously required 3 lambdas (for
> > >example), now requires 4 lambdas.  There are at least 3 ways to
> > >accommodate this requirement:
> > >
> > >  1.  An external management system adds a lambda to both the routers
> > >      at either end and the optical switches (demonstrated at OFC).
> > >
> > >  2.  The router signals the requirement/desire for an additional
> > >      lambda to the adjacent optical switch which sets up a path.
> > >      This is the overlay model.  It can be trivially implemented with
> > >      MPLS by having the router send a loose source hop in the ERO
> > >      allowing the switch to create the path or reject the request.
> >
> > Curtis,
> >
> > Am trying to understand the model here. Does the overlay model
> > as you put above imply that the optical devices need to be mini-routers
> > in their own right? They have to be able to set up end-to-end optical
> > paths.. perhaps some kind of binding between the end-host IP address
> > and an addressing scheme for Optical devices.. ala ATM?
> > What does the overlay model entail?
>
> The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or
> CRLDP) in a manner similar to the ATM UNI setting up an SVC.
>
> Alternately, the lambdas can be set statically and the edge router
> simple advertises a Lambda-Switch Capable link ala
> draft-kompella-mpls-optical-00.txt (if I understand their intent wrt
> accommodating the overlay model).
>
> I don't think draft-kompella-mpls-optical-00.txt has all the details
> sufficiently ironed out for the case where the optical switch
> advertises the availability of an optical link.  If it does, then the
> details ar just not clear to me.  (Could be my careless reading).
>
> > >  3.  The router has enough information about the characteristics of
> > >      the optical devices to compute the path and so it does so.  This
> > >      is the peer model.
> > >
> >
> > What does this model need.. a protocol for exchanging information
> > between the router and the optical device?
>
> It needs a means to communicate OOB wrt the primary lightpath.  That
> means would again be running the IGP and RSVP.  Based on reading the
> draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the
> optical switch exchanges this information OOB although I would imagine
> that it would be quite easy to maintian another interface (perhaps
> even an electrical, though gig-E would do fine) between the router and
> optical device in which the optical device advertises the optical
> links.  The router on either end of an optical link, seeing or having
> set up a Packet-Switch Capable link would then have to bring up an
> RSVP adjacency over it, though I think it would not need an IGP
> adjacency.  (I'm not clear on this last point.)
>
> The availability of certain types of links (Packet-Switch Capable,
> Lambda-Switch Capable, Fiber-Switch Capable) as defined in
> draft-kompella-mpls-optical-00.txt would be advertised via RSVP.  I'm
> not clear on whether the adjacent LSR should advertise a Forwarding
> Adjacency PSC after RSVP comes up over a set of optical links (it
> seems to be the intent) but maybe the authors can clarify the usage.
>
> The ongoing discussion and the topic of the (way too numerous)
> framework documents floating around has been what additional
> information would be needed in order to provide adequate constraints
> to set up optical paths, a particularly difficult problem for
> transparent paths.
>
> > -jagan.
> >
> > >The way this might manifest itself is LSPs that might take an optical
> > >path from A to C are going from A to B to C because A to C lambdas are
> > >too full.  If so, then A could in principle request an additional
> > >lambda, but in practice the means to signal this has not been defined.
> > >
> > >Curtis
> >
> > Jagannath Shantigram
> > Photonex Corporation
>
> btw- I exchanged some private email with one of the authors of
> draft-kompella-mpls-optical.txt and owe them some detailed comments
> (appologies to them for the delay, busy).  After some brief discussion
> and after a second reading, the intent seems a lot more clear.  The
> usage material is at the end so when reading the document from front
> to back the intent is not clear until the end and then a second
> reading is required.
>
> Curtis
>

---

From: Shen Gangxiang <[email-masked]>
Date: Fri, 24 Mar 2000 10:50:52 +0800

Hi,

To my knowledge, currently there seems no OXC product (commercially
announce) supporting all-optical wavelength conversion. The all-optical
wavelength converter is still costly and also not very mature. 

Gangxiang

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 11:32 PM
To: [email-masked]
Subject: Re: Comments on draft-ip-optical-framework-00.txt

There have been many discussions about wavelength conversion. And we all
agree
it is good. Can anyone tell me which OXC product (commercially announced)
doesn't support wavelength conversion?

Yangguang

---

From: "Berthold, Joseph" <[email-masked]>
Date: Fri, 24 Mar 2000 09:31:19 -0500

It should not matter what technology an OXC product uses to support wavelength conversion. When an all optical technology is the best economic and technological choice it will be used. 

Currently wavelength conversion is accomplished by O/E/O conversion, and includes 3R regeneration as an extra bonus. Not all OXCs support wavelength conversion, but the ones that do remove most of the transmission impairments. 

When we have all-optical wavelength conversion we will see if it comes with a 3R function that works as well as O/E/O. If it dosen't we will need to keep track of transmission impairments in making the routing decision, as we need to do today for all optical OXCs.

Joe

> ----------
> From: 	Shen Gangxiang
> Sent: 	Thursday, March 23, 2000 9:50 PM
> To: 	'Yangguang Xu'; [email-masked]

---

From: HYADUCKJ <[email-masked]>
Date: Fri, 24 Mar 2000 10:58:02 -0500

I believe the open model refers to areas not requiring constraints.  The
standardization process itself is a contraint system to specify limits and
requirements on implementations.  Where limits and other rigors are not
essential for interoperability a case can be made for allowing "freedom to
innovate" within a standardized framework.  The constraints here apply to
the "well defined interfaces" and allow for hiding (and later re-engineering
or replacement) of the substrata.  John

*3. Open Model
*In this scenario the optical layer comprises of several "vendor/network
operator clouds" that have *well defined interfaces. For example, an Optical
UNI can be used to interconnect the IP router to *the OXC and the Optical
NNI can be used to connect two optical network domains together. Here the
*optical layer is "fat, smart and agile".

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 4:54 PM
To: 'Krishna Bala'; [email-masked]; Jagan Shantigram
Cc: Khaled Elsayed; [email-masked]; [email-masked]
Subject: RE: Comments on draft-ip-optical-framework-00.txt 
>precludes an optical UNI in this model..

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 31 Mar 2000 16:19:59 -0500

A phone call from Yakov in response to my original message has highlighted
two points I didn't cover; one an assumption that I didn't clearly state,
and the other an important corollary I didn't pick up on. Here they are.

    > In the optical case, we have an *additional* constraint, which is
    > that even if people *outside* the optical part *did* have a full map,
    > they wouldn't necessarily be able to use it - because finding optical
    > paths is a process that has unusual constraints.

I'm making an unstated assumption here, one that I'll now put openly.

To begin with, my (limited :-) understanding of optical constraints is that
they fall into two classes; i) constraints associated with a particular
toplogy element (e.g. some OXC's can only switch in groups of lambdas), and
ii) constraints which are related to a path, rather than a particular
topology elements (e.g. total loss of signal strangth over a path).

(The difference is important because they are supported very differently by
the routing mechanism: the first kind one would typically see advertised as
attributes of the appropriate topology element; the second kind are ones
that the path-selection algorithm has to have built in.)

Now, the important issue in finding paths which meet optical constraints is
not whether you are 'inside' or 'outside', but *whether you understand
these constraints*! If you do understand them, then you can select paths
yourself, and it doesn't matter whether you are inside or outside.

In my original comment above, I was assuming that these special constraints
of the optical network were not understood by path-selection agents outside
the optical part of the mesh. Obviously, if that assumption is not true,
then the conclusions I drew from it (that "you're forced to produce a model
of the connectivity across [the optical] part of the connectivity graph")
don't happen.

    > Obviously, in a real network, everyone can't have a full graph of the
    > network. So you *have* to produce simplified representations - and
    > accept that some paths are going to be non-optimal. In other words,
    > you have to trade-off two kinds of overhead: routing overhead ..
    > and non-optimal paths. ...
    > you're forced to produce a model of the connectivity across that part
    > of the connectivity graph; i.e. select a set of paths, and advertise
    > that set of paths as the connectivity graph which is a virtual
    > representation of the connectivity of that part of the network.

I missed something important here.

I implied that bounding the overhead cost of the routing is the principal
reason why one would do an abstraction (with its attendant costs in
obscuring useful paths). However, I missed something important, something
connected to something I said below:

    > the problem will be easier to tackle in a system which uses a uniform
    > routing system at both the local and higher layers. Whatever
    > information flow you *do* decide to do (i.e. whatever virtual
    > representation of the local topology you do decide to propogate out
    > to the higher layer), you will have more flexibility in doing so if
    > the two are using the same routing system.

Sometimes you *don't want* to do an abstraction. However, when one is using
separate routing systems for 'inside' and 'outside', there's often *no way* to
provide the 'real' map - and you wind up providing an abstraction, whether you
like it or not. (I.e. the tradeoff you would prefer, between the two kinds of
overhead above, is to pay the routing cost, and not lose any potential paths.)

So there are real-world circumstances (driven by what tools exist) where one
winds up doing abstraction - but not because one has any fundamental need or
desire to (because of the inevitable costs of abstraction), but only because
that's the only choice the current technology gives you.

However, e.g. use of separate control planes for 'inside' and 'outside' has
basically made it impossible to do anything *but* provide an abstraction. And
that abstraction is usually one that has negative effects on the routing - N^2
links, or extra hops, or whatever.

(Now that I think about it, I guess this actually does fall under the
general statement that:

    > Whatever information flow you *do* decide to do (i.e. whatever virtual
    > representation of the local topology you do decide to propogate out
    > to the higher layer), you will have more flexibility in doing so if
    > the two are using the same routing system.

but I guess it's not necessarily immediately obvious, from this generic
statement, that this particular problem is an example of "[less]
flexibility"!)

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 31 Mar 2000 19:00:04 -0500

> From: Curtis Villamizar <[email-masked]>

    > Your lengthy message was trimmed before replying.

Take my PC-conjugal-unit, please! :-)

    >> something less than full N^2. This has the limitation that paths
    >> through the fabric between routers X and Y may actually exist - but
    >> such a path is not represented in our "virtualization" ... the only
    >> way to get from X to Y is to find some router Q ... take an "extra
    >> hop" through it.
 
    > In optical networks there is a good reason to do this. ... very
    > little traffic from A to C ... If you only set up a path from A to B
    > and B to C, you can still get from A to C without congestion, and you
    > use one less lambda.

Sure, that makes sense.

Note that in this case the *actual* interconnectivity topology among A, B
and C (A->B and B->C) matches the *representation* of the interconnectivity
topology. So your point is more about what *real* connections it makes
sense to create, than about what *representation* of those connections to
export to the routing outside.

    >> You can go on for a while, trying different things, and you soon
    >> discover a simple truth: in basically all real networks, there's *no*
    >> virtual representation of a part of the topology graph which is both
    >> i) simpler than the full representation, and ii) accurately and fully
    >> describes the connectivity through that part of the graph.
 
    > This is not a problem.
 
YMMV.

    >> where does this leave us, here in the real world, with the real tools
    >> at our disposal - tools which unfortunately don't allow us to create
    >> any virtual representation, but just a few selected ones? ... the
    >> main conclusion is that if you're producing non-optimal results,
    >> it's not necessarily because your tools are bad - it's an impossible
    >> problem even with the best possible tools.
 
    > Depends on your view of optimal. If you are optimizing your use of
    > the available lambdas, then not creating a path from A to C in the
    > above example is optimal

Sure, absolutely. But that's an optimization too, just (as you point out)
along a different axis than "shortest path for all traffic).

With a bit of work (which I'm too lazy to do, but I'm certain it is doable) I
can find scenarios where you can't perform an optimization of *that* kind, one
that you'd like to do, because of information loss due to the abstraction
process.

    > Whether this optimization is best done offline is still an open issue.

My sense is that "here in the future", we'll want to have tighter
integration between online (i.e. dynamic) routing stuff, and offline
analysis and simulation tools.

(By 'online stuff', I mean not just path-selection stuff, but also issues
like 'what underlying connectivity do I want to set up' and 'what
abstraction of that connectivity do I pass out' [N.B. the null-abstraction
- i.e. the full map - is one possible value for 'what abstraction'].)

I include simulation since a lot of these problems don't have closed-form
optimal solution algorithms (at least ones that aren't NP), and we'll wind
up picking a 'good-looking' guess and simulating to see how well it works.

    > Another way of thinking of this is that bypassing LSRs with optical
    > paths and not doing the electrical routing will always be making
    > slightly less efficient use of the lambdas that it is using than if
    > the lambdas were terminated and routed.

Really? If you were thinking of setting up an LSP from A to B, with
bandwidth X, where X is a full lambda, how is setting up a lamda directly
any less efficient? And it offloads all the LSR's in between...

Isn't the issue more one of matching resources needed to the quantae in
which resources are available? I.e. if you need 1/2 a lambda of bandwidth
between A and B, setting up a whole lambda between A and B *may* produce
some unused bandwidth... Unless the routing system can compensate and
produce paths (at the non-optical level, i.e. switched) from Pi to Qj which
include the A-B link, and the bandwidth needs of which sum to use up the
'extra' capacity on the A-B link.

All very complicated, I know! O(N^j) complexity, with all the different
options...

    > OTOH if lambdas are available and cheaper to use than additional
    > routing capacity, then from a dollar cost standpoint, the network
    > would be better off bypassing some of the routers with PSC tunnels
    > that are optically switched.

Sure. But go back to my point about - any optimization (along whatever axis
is important to you, including this one) may be harder to achieve if
topology information is hidden (aka lost) in the abstraction process.

    > The point of my earlier message was that we need a signaling
    > mechanism that does not constrain us down the road and some of the
    > internet drafts seem to allow that. ...
    > There is still plenty of work to be done to make the peer model work
    > ... but the signaling won't be a restriction if it is designed to
    > accomodate all three methods. Additional information will have to be
    > flooded later for the peer method to work but the setup is not likely
    > to need change.
 
I didn't quite follow this - I think the jargon being used is some I don't
quite grok. Let me try saying that I think you're saying, and you can tell
me if I got it right.

There are a numerous different models for how one would set up a path
across an "MPLS on top of optical" substrate. Along one axis, one could be
i) fully optical, ii) fully MPLS, iii) some mixture. Along another axis,
one could i) fully specify the path, ii) partially specify the path, etc.

In any event, if we have a path setup protocol (i.e. separate from the
path *selection* part of the process) which can handle all these variations,
we won't need to change *that* down the road, when the method by which we
discover and select paths changes.

Is that it?

	Noel