Routing over Demand Circuits

[Gerry Meyer <[e-mail]>]

The issue we are trying to resolve is - what is the most appropriate method
to operate on demand circuits with RIP protocol variants (IP, Novell, Apple
etc):

(a) an appropriate unreliable service (UDP-IP, IPX etc) which is what we
    currently use and is proposed in the Internet Draft.

(b) over a single reliable transport (TCP, encapsulating Novell RIP etc),

(c) the 'appropriate' reliable transport (TCP for IP, NCP or SPX for Novell
    etc).

In my original mailing I ruled out (c) immediately as requiring transports
not otherwise required in a multi-protocol router.

In the text which follows below I explain reasons why case (b) - encapsulating
routing information for all protocols in TCP - would be a poor choice.

I conclude that the proposal in my Internet Draft - to use an unreliable
datagram service (UDP, IPX etc) - is the correct one for handling
multi-protocol RIP variants.

	Comments (preferably favourable) on my conclusion?

		Gerry

             ++++++++++++++++++++++++++++++++++++++++++++

Input to my Conclusion
----------------------

1. Path Constraint
------------------

In its current state of development, Presumption of Reachability REQUIRES
that advertisement of routing information AND the routes being advertised
MUST follow NOT ONLY the same path, BUT utilise the SAME Virtual Circuit(s).

This means that advertising of one protocol through another (ie encapsulation
in TCP) will not work in cases where each protocol has its own VC (eg RFC 1356
when protocols are not multiplexed, but each have their own VC).

2. End-to-End Reliability
-------------------------

Each routing application must be able to guarantee that messages can be sent
to and received from its peer application in the remote router.

TCP in itself does NOT achieve this.  Each routing application needs to know
that its peer routing application is functioning.  Additional mechanisms must
be used to achieve this.

3. Stale Information
--------------------

If there are temporary problems with obtaining VCs, a number of routing
updates may be queued for transmission by TCP:

1) Eventually Stale information will be propagated and there may be
   further delay(s) before the up-to-date information is sent (eg. if there
   is contention for the VC resource).

   In some topologies these glitches could have fairly undesirable
   consequences.

2) Memory will be gobbled up in queued updates.

In my view these two factors completely rule out the use of TCP for RIP-like
applications.

4. Effort to implement a solution
--------------------------------- 

At the Amsterdam meeting there was a PERCEPTION that the UDP-like solution
required more support to be added into the routing applications than might
be the case for an encapsulated TCP solution.

However because TCP does not guarantee peer-to-peer reliability for EACH
routing application the perception turns out to be FALSE.

Appendix - TCP Stack
--------------------

The following is a pseudo-TCP stack (as suggested by someone at the
meeting - but it could possibly be compacted a bit):

     --------    ---------  ---------
     |IP-RIP|    |IPX-RIP|  |IPX-SAP|
     --------    ---------  ---------
        |            |          |
     --------        |          |
     | UDP  |        |          |
     --------        |          |
        |            |          |       ------------------------------
     --------    --------------------   |Stack(s) for other protocols|
     |  IP  |    |       IPX        |   |with RIP-based routing      |
     --------    --------------------   ------------------------------
        |                 |                           |
     -----------------------------------------------------------------
     | TCP-call manager, packetiser and de-multiplexer module        |
     -----------------------------------------------------------------
                                  |
                               -------
                               | TCP |
                               -------
                                  |
                               -------
                               | IP  |
                               -------

Parts of the 'stack' appearing above the TCP-call manager (UDP/IP etc)
carry some of the information and preserve packet format (but don't
otherwise functionally operate like a real protocol stack).  An Ethernet
type would be used for multiplexing information from the different protocols.