[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 RFC 1581

Network Working Group                                         G.M. Meyer
Internet Draft                                            Spider Systems
Expires Jun 21, 1994                                            Dec 1993


   Protocol Analysis for Extensions to RIP to Support Demand Circuits
                    draft-meyer-rip-analysis-02.txt


Status of this Memo

   This memo is being distributed to members of the Internet community
   in order to solicit their reactions to the proposals contained in it.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.  Internet Drafts are draft
   documents valid for a maximum of six months.  Internet Drafts may be
   updated, replaced, or obsoleted by other documents at any time.  It
   is not appropriate to use Internet Drafts as reference material or to
   cite them other than as a ``working draft'' or ``work in progress.''
   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

   Distribution of this memo is unlimited.

Abstract

   As required by Routing Protocol Criteria [1], this report documents
   the key features of Routing over Demand Circuits on Wide Area
   Networks - RIP [2] and the current implementation experience.

Acknowledgements

   I would like to thank colleagues at Spider, in particular Richard
   Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP
   and SAP implementations.











Meyer                                                           [Page 1]


Internet Draft        Demand RIP Protocol Analysis              Dec 1993


1. Protocol Documents

   "Extensions to RIP to Support Demand Circuits" [2] suggests an
   enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2"
   [4] to allow them to run more cost-effectively on Wide Area Networks
   (WANs).  Network management extensions for Demand RIP are described
   in RIP Version 2 MIB Extensions [5].

2. Applicability

   Demand RIP requires that there is an underlying mechanism for
   determining unreachability in a finite predictable period.

   The demand extensions to RIP are particularly appropriate for WANs
   where the cost - either financial or packet overhead - would make
   periodic transmission of routing (or service advertising) updates
   unacceptable:

   o  Connection oriented Public Data Networks - for example X.25 packet
      switched networks or ISDN.

   o  Point-to-point links supporting PPP link quality monitoring or
      echo request to determine link failure.

   A demand RIP implementation runs standard RIP on Local Area Networks
   (LANs) allowing them to interoperate transparently with implementa-
   tions adhering to the original specifications.

3. Key Features

   The proposal shares the same basic algorithms as RIP or RIP-2 when
   running on LANs or fixed point-to-point links; Packet formats, broad-
   cast frequency, triggered update operation and  database timeouts are
   all unmodified.

   The new features operate on WANs which use switched circuits on
   demand to achieve intermittent connectivity.  Instead of using
   periodic 'broadcasts', information is only sent as triggered updates.
   The proposal makes use of features of the underlying connection
   oriented service to provide feedback on connectivity.

3.1 Triggered Updates

   Updates are only sent on the WAN when an event changes the routing
   database.  Each update is retransmitted until acknowledged.  Informa-
   tion received in an update is not timed out.

   The packet format of a RIP response is modified (with a different



Meyer                                                           [Page 2]


Internet Draft        Demand RIP Protocol Analysis              Dec 1993


   unique command field) to include sequence and fragment number infor-
   mation.  An acknowledgement packet is also defined.

3.2 Circuit Manager

   The circuit manager running below the IP network layer is responsible
   for establishing a circuit to the next hop router whenever there is
   data (or a routing update) to transfer.  After a period of inactivity
   the circuit will be closed by the circuit manager.

   If the circuit manager fails to make a connection a circuit down
   indication is sent to the routing application.  The circuit manager
   will then attempt at (increasing) intervals to establish a connec-
   tion.   When successful a circuit up indication is sent to the rout-
   ing application.

3.3 Presumption of Reachability

   In a stable network there is no requirement to propagate routing
   information on a circuit, so if no routing information is (being)
   received on a circuit it is assumed that:

o  The most recently received information is accurate.

o  The intervening path is operational (although there may be no current
   connection).

   If the circuit manager determines that the intervening path is NOT
   operational routing information previously received on that circuit
   is timed out.  It is worth stressing that it can be ANY routed
   datagram which triggers the event.

   When the circuit manager re-establishes a connection, the application
   exchanges full routing information with its peer.

3.4 Routing Information Flow Control

   If the circuit manager reports a circuit as down, the routing appli-
   cation is flow controlled from sending further information on the
   circuit.

   To prevent transmit queue overflow and also to avoid 'predictable'
   circuit down messages, the routing application can also optionally
   limit the rate of sending routing messages to an interface.







Meyer                                                           [Page 3]


Internet Draft        Demand RIP Protocol Analysis              Dec 1993


4. Implementations

   At this stage there is only believed to be one completed implementa-
   tion.

   The Spider Systems' implementation supports all the features outlined
   for IP RIP-1, IPX RIP and IPX SAP.  RIP-2 is not currently supported.
   It has been tested against itself on X.25 and ISDN WANs.  It has also
   been tested in operation with various router and host RIP-1, IPX RIP
   and IPX SAP implementations on Ethernet LANs.

   Two other Novell-only implementations are known to be under develop-
   ment.

5. Rrestrictions

   Demand RIP relies on the ability to place a call in either direction.
   Some dialup services - for example DTR dialing - allow calls to be
   made in one direction only.

   Demand RIP can not operate with third-party advertisement of routes
   on the WAN.  The next hop IP address in RIP-2 should always be
   0.0.0.0 for any routes advertised on the WAN.

6. Security Considerations

   Security is provided through authentication of the logical and physi-
   cal address of the sender of the routing update.  Incoming call
   requests are matched by the circuit manager against a list of physi-
   cal addresses (used to make outgoing calls).  The routing application
   makes a further check against the logical address of an incoming
   update.

   Additional security can be provided by RIP-2 authentication [2] where
   appropriate.

References


   [1]  Hinden, R., "Internet Engineering Task Force Internet Routing
        Protocol Standardization Criteria", RFC 1264, Bolt Beranek and
        Newman, Inc, October 1991.

   [2]  Meyer. G.M., "Extensions to RIP to Support Demand Circuits",
        Internet Draft "draft-meyer-demandrouting-03.txt", Spider Sys-
        tems, Nov 1993.

   [3]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers



Meyer                                                           [Page 4]


Internet Draft        Demand RIP Protocol Analysis              Dec 1993


        University, June 1988.

   [4]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
        RFC 1388 Xylogics, 1992.

   [5]  Malkin. G.S. and Baker. F., "RIP Version 2 MIB Extensions",
        Internet Draft, Xylogics and ACC, 1993.

Author's  Address:

   Gerry Meyer
   Spider Systems
   Stanwell Street
   Edinburgh EH6 5NG
   Scotland, UK

   Phone: (UK) 31 554 9424
   Fax:   (UK) 31 554 0649
   Email: gerry@spider.co.uk
































Meyer                                                           [Page 5]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/