Hello Clare,
<Somewhat off topic ... but relates to Cisco technology ...>
> Scott, how do you define higher-layer object routing? Is
> it source route bridging or something? Hasn't that solution
> been shown to be unable to scale?
No ... not source routing. What you are possibly thinking of would be this "tag switching" ... just like source routing. Put a "tag" in the packet to indicate the switch path.
The entire concept of packet routing was that we had these little "objects" that we wanted to efficiently transfer from one end node to another. But two major issues have contributed, IMHO, to bandwidth problems and a need to rethink the model of routing.
The first issue is the size of "objects" that we want to transfer. Web pages, GIFs, JPGs, audio, video ... all of these things have grown beyond the size of a packet. So now we have a network infrastructure which is flooded with billions of small packets that are "pieces of objects" transferred between end nodes through "packet routers." When my web browser wants to open a new web page it sends a request (which is broken up into a small number of packets) to a web server. The web server then sends that page/graphic/object (which is broken up into a small or large number of packets) back to my browser. So I sent a small object to the web server and it sends an object back to me.
So a packet is not necessarily a good representation of what we want to route ... we really are trying to "route" the object from some server to our workstation, or workstation to server. Your browser is asking the web server to "route" a web page, through the Internet, to your workstation. (This *is* a weird concept, but once you see this then other parts of this concept will fall into place.)
The second issue is the redundant nature of the "objects" that are in demand in our world. How many of us visit the same web sites and access the same "objects" ... web pages, GIFs, JPGs, etc. etc. etc. The current packet routing model does not allow an easy solution to "caching" these objects so that if multiple users on a subnet request an object it can be given to the subsequent users from a local cache.
Packet routing, related to this issue, does not provide for any solution except for end-to-end packet level communications. Every time I want to see the WSJ on their web server, IP packets go from my house here in Utah, all the way across the country to New York, and all the way back. If I then walk outside and tell my neighbors about the article I read, and if my neighbors go there a minute later, their browser will send IP packets all the way across the country and back. Even though I had just requested these same "objects" be brought to my browser in Utah minutes earlier, duplicate copies are sent to my neighbor. Redundant, exact duplicate, wasted traffic.
Proxy/Caching (which is the foundation for "object routing"), at higher application layers, provides a mechanism to solve both of these problems - communications between object routers is at a higher layer, and caching and aging of objects solves the redundant traffic issues at a local level. (Also, IMHO there will be end-to-end node communications for the foreseeable future, but the objective is to minimize this.)
> Imagine each end-station
> having to send out explorer packets to find the route to
> a destination, and then encode the instructions into every
> packet they send. And because the complete routing information
> is in every packet header, the switching can't be as fast
> because each switch has to locate the position the instructions
> relevant to itself inside the header.
Again, what you are describing is more like the "tag switching" or "source routing" concepts. What I am suggesting is that you would have a "default object router" on your segment, just like you have a "default router" defined in your IP stack today.
> IMHO point-to-point object routing requires connection-oriented
> setup and teardown, and doesn't scale.
Yes on connections, and no about scaling.
Yes, these object routing concepts are applied to connection-oriented protocols ... but what application that *you* are running is not connection-oriented? HTTP, FTP, SMTP, POP3, NNTP ... and on and on. They are all connection-oriented. And since we would be doing object routing at this layer, we are simply using the application connections.
But I do not agree at all about your opinion on scaling. It *does* scale ... extremely well.
> Layer 3 routing is hierarchical in nature and reduces complexity
> for end-stations, as well as intermediary routers. Hierarchical
> systems, like telephone numbers, post office addressing/zip codes,
> and IP addresses scale precisely because an end-station does not
> know nor has to care about the exact route to a destination.
Yes ... and in hierarchical proxy/caching/object routing the end node only knows how to talk to the local object router on their segment. And the end users don't even know (unless they are allowed to!) whether they got a local cache copy of the object, or one from an object router two hops away, or ten hops away, or the origin server. Internet Caching Protocol (ICP) is the mechanism for creating hierarchical neighborhoods.
> In anycase, you cannot eliminate lower layer switching unless you
> were directly connected.
Yes. ;-)
If you look at today's packet routers ... they are directly connected. And so object routers, while able to operate over existing packet routed infrastructures, will really scream when they are directly connected.
And so why does this make a difference to Cisco? I'm an investor in Cisco, and am not selling my Cisco stock today. But I feel that object routing *will* have an impact in the next year. With Intel pushing into the networking business, and products like Novell's FastCache (a first generation object router) running on Intel commodity platforms, I have to imagine that the benefits will start to show. Proprietary hardware vs. "Intel standard platforms" ... hmmm I wonder how well that will go over ...
I'm not too attached to my perceptions and am always learning. Just some attempts to predict the future ... which is always dangerous! ;-)
Scott C. Lemon |
