Path: utzoo!attcan!uunet!samsung!usc!apple!amdahl!pacbell!att!cbnewsh!tds From: tds@cbnewsh.ATT.COM (antonio.desimone) Newsgroups: comp.protocols.tcp-ip Subject: Routing Protocols Keywords: igp, cisco, bbn, milnet, congestion Message-ID: <6007@cbnewsh.ATT.COM> Date: 22 Nov 89 01:10:58 GMT Organization: AT&T Bell Laboratories Lines: 101 Some time back I posted this query (actually a longer version) looking for information on cisco's routing protocol. > Can someone point me to a source of information on cisco's > Interior Gateway Routing Protocol? I've come across some of their > glossies that make mention of flow optimization, delay and traffic > measurements, etc. I wonder if they do something much more > sophisticated than, for example, Open SPF as far as load balancing > Beyond cisco in particular, are there any IP router vendors who > attempt to make routing decisions based on real-time traffic > measurements? Thanks to all those who replied: I quote from some replies below. Kent> kwe%buitb.BU.EDU@bu-it.bu.edu (Kent England) John> John Bashinski smb> ulysses!smb Milo> "Milo S. Medin" art> art@sage.acc.com First the quick summary: get the document describing IGRP written by Chuck Hedrick from Rutgers. Hedrick was good enough to send me a copy but I won't bother posting since it's available by anonymous ftp from: Kent> athos.rutgers.edu in /pub/igrp.[doc|ps]. It might Kent> be or will be in the Working Group directories on SRI-NIC at some Kent> point. John> You can pick up a copy of a paper on IGRP by anonymous FTP from John> ftp.cisco.com. It's called "igrp.doc". Directory listings are disabled John> for security reasons; just go ahead and pick up the paper. Basics: Kent> Well, the main diff is link-state versus distance-vector. OSPF is Kent> link-state and ciscoIGRP is distance vector. Depending on which side Kent> you light your torch, you might prefer one over the other based on Kent> link-state or distance-vector. Art> Until recently, IGRP was not being disclosed by cisco. At the last IETF, Art> Chuch Hedrick at Rutgers released a document (with cisco's OK), based Art> on the cisco patent application, which summarizes the major technology Art> in IGRP. From looking at that, I would say that OSPF and IGRP offer about Art> the same level of functionality. Of course, since IGRP is a Distance Vector Art> algorithm and OSPF is a Link State algorithm, this is somewhat apples to Art> oranges. cisco has apparently stated that they may be willing to liscense Art> IGRP much like Ethernet was (modest one time charge). Chuch Hedrick is Art> heading an IETF working group looking into defining a public domain Distance Art> Vector protocol that would be equal to or better than IGRP. On the issue of load balancing: John> IGRP provides for just slightly more than plain round-robin routing; you John> can specify a "variance", which allows load-sharing between links with John> different capacities. Unfortunately, large variances tend to destabilize John> the network. Milo> Just a point of clarification here about OSPF. The protocol will find Milo> multiple equal-cost paths. Whether or not a router can use this Milo> information to load-balance in a round-robin way depends on how Milo> the IP forwarding module in a particular implementation is implemented. Milo> In general trying to do dynamic load balancing in a multi-vendor Milo> environment is a pretty dicey issue. BBN went through great pains Milo> to tame the dynamic load balancing in their PSN networks. And on the use of measures of real-time congestion for routing: (I don't know if I was completely clear in my original posting. I was asking about controls that respond on the timescales on which queues build up. That's what is required to reroute rather than drop packets as queues build up, i.e. if you want "congestion avoidance".) smb> As for delay measurements: what about the ARPANET itself, where the IMPs smb> do real-time load measurements? That was certainly an operational net, smb> and MILNET still uses that technology. Art> The stability problems seem to outweigh any real benefits at the current Art> time. Until congestion avoidance mechanisms for connectionless networks Art> are developed (and deployed) to deal congestion in the first place, I Art> don't think it makes sense to try to respond to congestion at the routing Art> level. Once congestion avoidance mechanisms are there, and the routers Art> can determine the rate at which sources respond to congestion (not an easy Art> measurement problem) then that gives a limit to how fast routing should Art> be allowed to change. Art's statement seems to hold for the BBN/Milnet algorithm as well. There's an article in the recent SIGCOMM proceedings by Khanna and Zinky of BBN that explains the metric used. Yes delay measurements are used, but routes are updated on a timescale in the tens of seconds, at best. That approaches the connection (or at least the busy) time for file transfers. I think it's safe to say that no one uses rerouting as a congestion avoidance technique (although I'd still be interested to hear otherwise!) -- Tony DeSimone AT&T Bell Laboratories Holmdel, NJ 07733 att!tds386e!tds