1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1581.txt b/doc/rfc/rfc1581.txt
new file mode 100644
index 0000000..7cc1bc7
--- /dev/null
+++ b/doc/rfc/rfc1581.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                           G. Meyer
+Request for Comments: 1581                                Spider Systems
+Category: Informational                                    February 1994
+
+
+   Protocol Analysis for Extensions to RIP to Support Demand Circuits
+
+Status of this Memo
+
+   This document provides information for the Internet community.  This
+   document does not specify an Internet standard of any kind.
+   Distribution of this document 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.
+
+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.
+
+
+
+Meyer                                                           [Page 1]
+
+RFC 1581                       Demand RIP                  February 1994
+
+
+   A demand RIP implementation runs standard RIP on Local Area Networks
+   (LANs) allowing them to interoperate transparently with
+   implementations 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,
+   broadcast 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.
+   Information received in an update is not timed out.
+
+   The packet format of a RIP response is modified (with a different
+   unique command field) to include sequence and fragment number
+   information.  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
+   connection.  When successful a circuit up indication is sent to the
+   routing 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:
+
+
+
+
+
+
+Meyer                                                           [Page 2]
+
+RFC 1581                       Demand RIP                  February 1994
+
+
+   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
+   application 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.
+
+4. Implementations
+
+   At this stage there is only believed to be one completed
+   implementation.
+
+   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
+   development.
+
+5. Restrictions
+
+   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.
+
+
+
+
+
+Meyer                                                           [Page 3]
+
+RFC 1581                       Demand RIP                  February 1994
+
+
+6. Security Considerations
+
+   Security is provided through authentication of the logical and
+   physical address of the sender of the routing update.  Incoming call
+   requests are matched by the circuit manager against a list of
+   physical 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.
+
+7. 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., "Extensions to RIP to Support Demand Circuits", RFC
+       1582, Spider Systems, February 1994.
+
+   [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
+       Rutgers University, June 1988.
+
+   [4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
+       RFC 1388, Xylogics, January 1993.
+
+   [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC
+       1389, Xylogics, ACC, January 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 4]
+
+\ No newline at end of file