GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2092

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

                                                            Shiva
                                                     January 1997
                Protocol Analysis for Triggered RIP

Status of this Memo

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

Abstract

 As required by Routing Protocol Criteria [1], this report documents
 the key features of Triggered Extensions to RIP to Support Demand
 Circuits [2] and the current implementation experience.
 As a result of the improved characteristics of Triggered RIP, it is
 proposed that Demand RIP [5] be obsoleted.

Acknowledgements

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

1. Protocol Documents

 "Triggered 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).

2. Applicability

 Triggered RIP requires that there is an underlying mechanism for
 determining unreachability in a finite predictable period.
 The triggered 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.

Sherry & Meyer Informational [Page 1] RFC 2092 Triggered RIP Protocol Analysis January 1997

 o  Point-to-point links supporting PPP link quality monitoring or
    echo request to determine link failure.
 A triggered 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; 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; Or on permanent WAN
 connections where there is a desire to keep routing packet overhead
 to a minimum.  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 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.

Sherry & Meyer Informational [Page 2] RFC 2092 Triggered RIP Protocol Analysis January 1997

3.3 Technology Restrictions

 There is a small but nontrivial possiblility of an incorrectly
 configured or poorly operating link causing severe data loss,
 resulting in a 'black hole' in routing. This is often unidirectional
 - the link that route updates cross works properly, but not the
 return path.
 Triggered RIP will NOT fuction properly (and should NOT be used) if a
 routing information will be retained/advertised for an arbitrarily
 long period of time (until an update in the opposite direction fails
 to obtain a response).
 To detect black holes in technologies which use PPP encapsulation,
 either Echo Request/Response or Link Quality Monitoring should be
 used.  When a black hole is detected a circuit down indication must
 be sent to the routing application.
 Current (and future) technologies which do not use PPP, need to use
 an equivalent 'are-you-there' mechanism - or should NOT be used with
 Triggered RIP.

3.4 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.5 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.

Sherry & Meyer Informational [Page 3] RFC 2092 Triggered RIP Protocol Analysis January 1997

4. Relationship to Demand RIP

 The Triggered RIP proposal [2] has a number of efficiency advantages
 over the Demand RIP proposal [5]:
 o  When routing information changes Demand RIP sends the full
    database to its partner.
    Once a router has exchanged all routing information with its
    partner, Triggered RIP sends only the changed information to the
    partner.  This can dramatically decrease the quantity of
    information requiring propagation when a route change occurs.
 o  Demand RIP requires a full routing update to be stored by the
    receiver, before applying changes to the routing database.
    A Triggered RIP receiver is able to apply all changes immediately
    upon receiving each packet from its partner.  Systems therefore
    need to use less memory than Demand RIP.
 o  Demand RIP has an upper limit of 255 fragments in an update.  This
    sets an upper limit on the sizes of routing and service
    advertising databases which can be propagated.
    This restriction is lifted in Triggered RIP (which does not use
    fragmentation).
 In all other respects Demand RIP and Triggered RIP perform the same
 function.

5. Obsoleting Demand RIP

 While it is possible that systems could be able to support Demand RIP
 and Triggered RIP, the internal maintenance of structures is likely
 to differ significantly.  The method of propagating the information
 also differs significantly.  In practice it is unlikely that systems
 would support Demand RIP and Triggered RIP.
 As a result of the improved characteristics of Triggered RIP, it is
 proposed that Demand RIP [5] be obsoleted.

6. Implementations

 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 IP
 RIP-1, IP RIP-2, IPX RIP, and IPX SAP.  However, it only supports one
 outstanding acknowledgement per partner.  The implementation has been
 tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs,
 and asynchronous modems.  It has also been tested in operation with
 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 ISDN
 without problems.

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

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

Sherry & Meyer Informational [Page 5] RFC 2092 Triggered RIP Protocol Analysis January 1997

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. and Sherry, S., "Triggered Extensions to RIP to
      Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995.
 [3]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
      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 Sherry
    Xyplex
    295 Foster St.
    Littleton, MA 01460
    Phone: (US) 508 952 4745
    Fax:   (US) 508 952 4887
    Email: shs@xyplex.com
    Gerry Meyer
    Shiva Europe Ltd
    Stanwell Street
    Edinburgh EH6 5NG
    Scotland, UK
    Phone: (UK) 131 561 4223
    Fax:   (UK) 131 561 4083
    Email: gerry@europe.shiva.com

Sherry & Meyer Informational [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2092.txt · Last modified: 1997/01/23 22:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki