RFC2092 Protocol Analysis for Triggered RIP

2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT=10865 bytes) (Status: INFORMATIONAL)

日本語訳
RFC一覧

参照

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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

開発中のアプリケーションを実機でテストする方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る