Subject: Re: (ION) Optical routing

From: [email-masked]
Date: Mon, 18 Sep 2000 11:41:35 EDT

In a message dated 9/18/00 10:20:47 AM Eastern Daylight Time, 
[email-masked] writes:

> Just for grins, did anyone see the articles in this month's IEEE
>  Communications Magazine, about IP over optical networks? It's the same old
>  issues all over again. Basically, you have IP over a circuit-switched
>  network again. They do offer different approaches, including having the
>  optical network also use IP addressing (in this respect, unlike IP over
>  ATM), but the end result still looks very much like IP over ATM or IP
>  directly over SONET.

Until one can build an optical packet switch (or at least an
optical register), not much else can be expected.

Joachim Martillo
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 18 Sep 2000 17:02:08 -0400

And to that end, we have MARS. RFC 2022, whose abstract reads like this:

Abstract

   Mapping the connectionless IP multicast service over the connection
   oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.
   This memo describes a mechanism to support the multicast needs of
   Layer 3 protocols in general, and describes its application to IP
   multicasting in particular.

   ATM based IP hosts and routers use a Multicast Address Resolution
   Server (MARS) to support RFC 1112 style Level 2 IP multicast over the
   ATM Forum's UNI 3.0/3.1 point to multipoint connection service.
   Clusters of endpoints share a MARS and use it to track and
   disseminate information identifying the nodes listed as receivers for
   given multicast groups. This allows endpoints to establish and manage
   point to multipoint VCs when transmitting to the group.

   The MARS behaviour allows Layer 3 multicasting to be supported using
   either meshes of VCs or ATM level multicast servers. This choice may
   be made on a per-group basis, and is transparent to the endpoints.

Note that ATM had an advantage compared with optical networks. ATM can
replicate cells at any switch, sending these to any number of output ports.
And RFC 2022 makes use of that capability to implement an RFC 1112-like IP
multicast service over ATM.

Optical nets would need some sort of optical amplifier at the divergence
points to achieve a similar capability, at which point in principle
something along the same lines as RFC 2022 could be adapted to optical nets.

Since it is feasible to use MARS to reach individual IP unicast addresses,
as well as ATM addresses (AESAs), it seems to me that this gives RFC 2022 a
reasonable shot at being the solution for optical nets, however they end up
being arranged.

I agree that multicast over IP seems to be a necessity in the future. As
some wise person once said, "If you think you have solved a problem, just
try implementing multicast."

Bert
[email-masked]

> -----Original Message-----
> From: Shawn Veillon [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 1:03 PM
> To: ION Group (E-mail)
> Subject: RE: (ION) Optical routing
> 
> 
> Well, I think more focus should be placed on implementing 
> multicast across
> the Internet.  Faster and wider is great, but more efficient 
> is smarter.
> Don't you think?  I know that won't solve everything, as 
> there will still be
> tons of downloading of files going on, but if the trend 
> continues in the
> arena of media casting, along with the move to wider use of 
> broadband in the
> home, we can expect THAT to become the majority usage.  
> Multicasting should
> help curb that.  It's closer than an optical packet switch.
> 
> We should do both, for sure.
> 
> Shawn Veillon
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Manfredi, Albert E
> Sent: Monday, September 18, 2000 7:14 AM
> To: ION Group (E-mail)
> Subject: (ION) Optical routing
> 
> 
> Hi IONers. Anyone still out there?
> 
> Aren't you glad ION went through all those hurdles before? 
> Perhaps we should
> add optical nets to the charter and reactivate ION. Makes sense to me.
> Optical nets are still non-broadcast nets, after all.
> 
> Regards
> 
> Bert
> [email-masked]
> ------- End of Forwarded Message ------- 
>

---

From: Michael Smirnov <[email-masked]>
Date: Mon, 18 Sep 2000 23:23:07 +0200 (MET DST)

Hi,

sounds like a good idea,

On Mon Sep 18 16:25:33 2000 Manfredi, Albert wrote:

<...>
	 Perhaps we should
> Optical nets are still non-broadcast nets, after all.

cheers

Michael

---

From: "Peter Tam" <[email-masked]>
Date: Mon, 18 Sep 2000 19:15:11 -0400

Albert:

How would it be different from the proposed work in the IP over Optics BOF
charter? 

Regards....Peter
Nortel Networks

	-----Original Message-----
	From:	Michael Smirnov [SMTP:[email-masked]]
	Sent:	Monday, September 18, 2000 5:23 PM
	To:	[email-masked]; [email-masked]
	Subject:	Re: (ION) Optical routing

	Hi,

	sounds like a good idea,

	<...>
		 Perhaps we should

	cheers

	Michael

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 24 Sep 2000 16:44:10 -0400

Fred Baker wrote:

> Sorry for the delay in responding; I have been in transit.
> 
> It was the comment, roughly verbatim, of a person who 
> attended the last 
> IETF to attend the BOF, whom I met in the airport. 
> Thankfully, I collected 
> neither his name nor that of his company. I was, er, sputter, ...
> 
> My perspective on MPLS is that it is a facility that has 
> certain potential 
> utilities, such as in BGP/MPLS VPNs and in Traffic Engineering. It is 
> essentially a circuit switching architecture, and is therefore not 
> connectionless. I rather believe that Len Kleinrock was onto 
> something in 
> his paper on the subject in 1964, and so get a little twitchy 
> at the thought.
> 
> I don't see the need for MPLS in the optical layer (unless 
> you view the 
> lambda frequency itself as the label), and it may get in the 
> way of some 
> interesting things; I'd rather not restrict things at this 
> point if I don't 
> have to. A lambda encodes a class of traffic. It may be "the 
> traffic going 
> to this next hop", "the traffic of this class going to this 
> next hop", "the 
> traffic of this class going to this set of next hops", or a 
> list of other 
> possibilities. In that latter case, I could imagine the set 
> of next hops 
> being linearly related along a fiber path (ie, several 
> successive systems 
> down one fiber path who each see the same light beam and each 
> extract a 
> subset of its contents), or the set being a POP (so that the 
> next hop is 
> the entry to the POP, and the data is then distributed among 
> systems at the 
> POP). The light beam is itself a "circuit" in some sense, ...

The articles that discuss this, in this month's IEEE Communications
Magazine, pretty much echo these thoughts. The different light beams are
indeed circuits, and in order to choose the right one, guess what we have?
We have a UNI and we have an NNI. Does any of this sound familiar?

I guess the reason I brought this up at all is to point out that at least
some, if not all, of the problems we encountered with ION, which ultimately
indirectly led to its becoming deactivated, will be repeated here. We are
still at the hype phase with respect to WDM, of course, but consider what
happens, for example, with the potential for routing loops when we try
routing IP packets through the optical network? Or how about multicast
support? The ATM experience could be useful here, to avoid the problems ATM
has with merging flows in a many-to-many multicast.

> Call it a preference or a religious opinion, if you need to 
> categorize 
> opinions. I would rather do my work at the IP layer.

If wavelengths could be assigned on a packet-by-packet basis, or at least on
an session-by-session basis (which isn't necessarily any easier to do,
especially with short HTTP-like transactions), these schemes, and ATM, would
be easier to use with IP packet switching philosophies, methinks.

Bert