Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!purdue!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip
Subject: Re: routing protocols
Message-ID: <42691@bu-cs.BU.EDU>
Date: 15 Nov 89 20:05:17 GMT
References: <5764@cbnewsh.ATT.COM>
Reply-To: kwe@bu-it.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston U. Information Technology
Lines: 38

In article <5764@cbnewsh.ATT.COM> 
tds@cbnewsh.ATT.COM (antonio.desimone) writes:
>Can someone point me to a source of information on cisco's
>Interior Gateway Routing Protocol?  

Chuck Hedrick from Rutgers recently announced formation of an Open
Distance Vector Routing Working Group within the IETF and has drafted
a paper on cisco's IGRP (with cisco's permission) as a candidate for
that protocol.  Anon ftp is available from one of several servers at
rutgers.edu.  Try athos.rutgers.edu in /pub/igrp.[doc|ps].  It might
be or will be in the Working Group directories on SRI-NIC at some
point.  So, for the first time, there is a rather complete description
of cisco's patented (or patent pending) algorithm.

>... I wonder if they do something much more
>sophisticated than, for example, Open SPF as far as load balancing
>(if I understand Open SPF, the protocol allows round-robin routing
>over equal shortest paths).

Well, the main diff is link-state versus distance-vector.  OSPF is
link-state and ciscoIGRP is distance vector.  Depending on which side
you light your torch, you might prefer one over the other based on
link-state or distance-vector.

>
>Beyond cisco in particular, are there any IP router vendors who
>attempt to make routing decisions based on real-time traffic
>measurements?  I'm not talking about neat experimental algorithms,
>or unused options in some protocol, but commercial (or at least
>widely used) implementations.  My impression, based on an
>admittedly cursory scan of the literature, is that a lot of
>interesting work has been done but nobody has solved the stability
>and measurement/timescale problems to the extent that someone
>would risk such an algorithm in an operational network or a
>commercial product. 

Oh, I don't know.  The first NSFnet backbone risked a delay/congestion
based algorithm on an operational (but noncommercial) network.