As per Relevance of the word networks, we have this rfc below:











Network Working Group G.
Request for Comments: 1581 Spider
Category: Informational February 1994


Protocol Analysis for Extensions to RIP to Support Demand

Status of this

This document provides information for the Internet community.
document does not specify an Internet standard of any kind
Distribution of this document is unlimited



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



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

1. Protocol

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

2.

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

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

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

o Point-to-point links supporting PPP link quality monitoring
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
(LANs) allowing them to interoperate transparently
implementations adhering to the original specifications

3. Key

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

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

3.1 Triggered

Updates are only sent on the WAN when an event changes the
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
unique command field) to include sequence and fragment
information. An acknowledgement packet is also defined

3.2 Circuit

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

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

3.3 Presumption of

In a stable network there is no requirement to propagate
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
current connection).

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

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

3.4 Routing Information Flow

If the circuit manager reports a circuit as down, the
application is flow controlled from sending further information
the circuit

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

4.

At this stage there is only believed to be one
implementation

The Spider Systems' implementation supports all the features
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
been tested in operation with various router and host RIP-1, IPX
and IPX SAP implementations on Ethernet LANs

Two other Novell-only implementations are known to be
development

5.

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

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





Meyer [Page 3]

RFC 1581 Demand RIP February 1994


6. Security

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

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

7.

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

[2] Meyer. G., "Extensions to RIP to Support Demand Circuits",
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",
1389, Xylogics, ACC, January 1993.

Author's

Gerry
Spider
Stanwell
Edinburgh EH6 5
Scotland,

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










Meyer [Page 4]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum