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











Network Working Group S.
Request for Comments: 2092
Category: Informational G.

January 1997


Protocol Analysis for Triggered

Status of this

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



As required by Routing Protocol Criteria [1], this report
the key features of Triggered Extensions to RIP to Support
Circuits [2] and the current implementation experience

As a result of the improved characteristics of Triggered RIP, it
proposed that Demand RIP [5] be obsoleted



The authors wish to thank Johanna Kruger and Jim Pearl of Xyplex
many comments and suggestions which improved this effort

1. Protocol

"Triggered Extensions to RIP to Support Demand Circuits" [2]
an enhancement to the "Routing Internet Protocol" (RIP) [3]
"RIP-2" [4] to allow them to run more cost-effectively on Wide
Networks (WANs).

2.

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

The triggered 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



Sherry & Meyer Informational [Page 1]

RFC 2092 Triggered RIP Protocol Analysis January 1997


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

A triggered RIP implementation runs standard RIP on Local
Networks (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; Packet formats, broadcast frequency,
update operation and database timeouts are all unmodified

The new features operate on WANs which use switched circuits
demand to achieve intermittent connectivity; Or on permanent
connections where there is a desire to keep routing packet
to a minimum. Instead of using periodic 'broadcasts', information
only sent as triggered updates. The proposal makes use of
of the underlying connection oriented service to provide feedback
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 number information.
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








Sherry & Meyer Informational [Page 2]

RFC 2092 Triggered RIP Protocol Analysis January 1997


3.3 Technology

There is a small but nontrivial possiblility of an
configured or poorly operating link causing severe data loss
resulting in a 'black hole' in routing. This is often
- the link that route updates cross works properly, but not
return path

Triggered RIP will NOT fuction properly (and should NOT be used) if
routing information will be retained/advertised for an
long period of time (until an update in the opposite direction
to obtain a response).

To detect black holes in technologies which use PPP encapsulation
either Echo Request/Response or Link Quality Monitoring should
used. When a black hole is detected a circuit down indication
be sent to the routing application

Current (and future) technologies which do not use PPP, need to
an equivalent 'are-you-there' mechanism - or should NOT be used
Triggered RIP

3.4 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

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.5 Routing Information Flow

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





Sherry & Meyer Informational [Page 3]

RFC 2092 Triggered RIP Protocol Analysis January 1997


4. Relationship to Demand

The Triggered RIP proposal [2] has a number of efficiency
over the Demand RIP proposal [5]:

o When routing information changes Demand RIP sends the
database to its partner

Once a router has exchanged all routing information with
partner, Triggered RIP sends only the changed information to
partner. This can dramatically decrease the quantity
information requiring propagation when a route change occurs

o Demand RIP requires a full routing update to be stored by
receiver, before applying changes to the routing database

A Triggered RIP receiver is able to apply all changes
upon receiving each packet from its partner. Systems
need to use less memory than Demand RIP

o Demand RIP has an upper limit of 255 fragments in an update.
sets an upper limit on the sizes of routing and
advertising databases which can be propagated

This restriction is lifted in Triggered RIP (which does not
fragmentation).

In all other respects Demand RIP and Triggered RIP perform the
function

5. Obsoleting Demand

While it is possible that systems could be able to support Demand
and Triggered RIP, the internal maintenance of structures is
to differ significantly. The method of propagating the
also differs significantly. In practice it is unlikely that
would support Demand RIP and Triggered RIP

As a result of the improved characteristics of Triggered RIP, it
proposed that Demand RIP [5] be obsoleted

6.

At this stage there are believed to be two completed implementation







Sherry & Meyer Informational [Page 4]

RFC 2092 Triggered RIP Protocol Analysis January 1997


The Xyplex implementation supports all the features outlined for
RIP-1, IP RIP-2, IPX RIP, and IPX SAP. However, it only supports
outstanding acknowledgement per partner. The implementation has
tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs
and asynchronous modems. It has also been tested in operation
various router and host implementations on Ethernet LANs

The DEC implementation supports IP RIP-1 over ISDN, Frame Relay
leased lines and V.25bis. The Xyplex and DEC IP RIP-1
implementations have been checked for interoperability over
without problems

7.

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

8. 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


















Sherry & Meyer Informational [Page 5]

RFC 2092 Triggered RIP Protocol Analysis January 1997




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

[2] Meyer. G.M. and Sherry, S., "Triggered Extensions to RIP
Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995.

[3] Hedrick. C., "Routing Information Protocol", RFC 1058,
University, June 1988.

[4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, November 1994.

[5] Meyer. G., "Extensions to RIP to Support Demand Circuits",
Spider Systems, February 1994.

Authors' Address

Steve

295 Foster St
Littleton, MA 01460

Phone: (US) 508 952 4745
Fax: (US) 508 952 4887
Email: shs@xyplex.

Gerry
Shiva Europe
Stanwell
Edinburgh EH6 5
Scotland,

Phone: (UK) 131 561 4223
Fax: (UK) 131 561 4083
Email: gerry@europe.shiva.













Sherry & Meyer Informational [Page 6]








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