home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2092.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  10.6 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     S. Sherry
  8. Request for Comments: 2092                                   Xyplex
  9. Category: Informational                                    G. Meyer
  10.                                                               Shiva
  11.                                                        January 1997
  12.  
  13.  
  14.                   Protocol Analysis for Triggered RIP
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    As required by Routing Protocol Criteria [1], this report documents
  25.    the key features of Triggered Extensions to RIP to Support Demand
  26.    Circuits [2] and the current implementation experience.
  27.  
  28.    As a result of the improved characteristics of Triggered RIP, it is
  29.    proposed that Demand RIP [5] be obsoleted.
  30.  
  31. Acknowledgements
  32.  
  33.    The authors wish to thank Johanna Kruger and Jim Pearl of Xyplex for
  34.    many comments and suggestions which improved this effort.
  35.  
  36. 1. Protocol Documents
  37.  
  38.    "Triggered Extensions to RIP to Support Demand Circuits" [2] suggests
  39.    an enhancement to the "Routing Internet Protocol" (RIP) [3] and
  40.    "RIP-2" [4] to allow them to run more cost-effectively on Wide Area
  41.    Networks (WANs).
  42.  
  43. 2. Applicability
  44.  
  45.    Triggered RIP requires that there is an underlying mechanism for
  46.    determining unreachability in a finite predictable period.
  47.  
  48.    The triggered extensions to RIP are particularly appropriate for WANs
  49.    where the cost - either financial or packet overhead - would make
  50.    periodic transmission of routing (or service advertising) updates
  51.    unacceptable:
  52.  
  53.    o  Connection oriented Public Data Networks - for example X.25 packet
  54.       switched networks or ISDN.
  55.  
  56.  
  57.  
  58. Sherry & Meyer               Informational                      [Page 1]
  59.  
  60. RFC 2092            Triggered RIP Protocol Analysis         January 1997
  61.  
  62.  
  63.    o  Point-to-point links supporting PPP link quality monitoring or
  64.       echo request to determine link failure.
  65.  
  66.    A triggered RIP implementation runs standard RIP on Local Area
  67.    Networks  (LANs) allowing them to interoperate transparently with
  68.    implementations adhering to the original specifications.
  69.  
  70. 3. Key Features
  71.  
  72.    The proposal shares the same basic algorithms as RIP or RIP-2 when
  73.    running on LANs; Packet formats, broadcast frequency, triggered
  74.    update operation and  database timeouts are all unmodified.
  75.  
  76.    The new features operate on WANs which use switched circuits on
  77.    demand to achieve intermittent connectivity; Or on permanent WAN
  78.    connections where there is a desire to keep routing packet overhead
  79.    to a minimum.  Instead of using periodic 'broadcasts', information is
  80.    only sent as triggered updates.  The proposal makes use of features
  81.    of the underlying connection oriented service to provide feedback on
  82.    connectivity.
  83.  
  84. 3.1 Triggered Updates
  85.  
  86.    Updates are only sent on the WAN when an event changes the routing
  87.    database.  Each update is retransmitted until acknowledged.
  88.    Information received in an update is not timed out.
  89.  
  90.    The packet format of a RIP response is modified (with a different
  91.    unique command field) to include sequence number information.  An
  92.    acknowledgement packet is also defined.
  93.  
  94. 3.2 Circuit Manager
  95.  
  96.    The circuit manager running below the IP network layer is responsible
  97.    for establishing a circuit to the next hop router whenever there is
  98.    data (or a routing update) to transfer.  After a period of inactivity
  99.    the circuit will be closed by the circuit manager.
  100.  
  101.    If the circuit manager fails to make a connection a circuit down
  102.    indication is sent to the routing application.  The circuit manager
  103.    will then attempt at (increasing) intervals to establish a
  104.    connection.   When successful a circuit up indication is sent to the
  105.    routing application.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Sherry & Meyer               Informational                      [Page 2]
  115.  
  116. RFC 2092            Triggered RIP Protocol Analysis         January 1997
  117.  
  118.  
  119. 3.3 Technology Restrictions
  120.  
  121.    There is a small but nontrivial possiblility of an incorrectly
  122.    configured or poorly operating link causing severe data loss,
  123.    resulting in a 'black hole' in routing. This is often unidirectional
  124.    - the link that route updates cross works properly, but not the
  125.    return path.
  126.  
  127.    Triggered RIP will NOT fuction properly (and should NOT be used) if a
  128.    routing information will be retained/advertised for an arbitrarily
  129.    long period of time (until an update in the opposite direction fails
  130.    to obtain a response).
  131.  
  132.    To detect black holes in technologies which use PPP encapsulation,
  133.    either Echo Request/Response or Link Quality Monitoring should be
  134.    used.  When a black hole is detected a circuit down indication must
  135.    be sent to the routing application.
  136.  
  137.    Current (and future) technologies which do not use PPP, need to use
  138.    an equivalent 'are-you-there' mechanism - or should NOT be used with
  139.    Triggered RIP.
  140.  
  141. 3.4 Presumption of Reachability
  142.  
  143.    In a stable network there is no requirement to propagate routing
  144.    information on a circuit, so if no routing information is (being)
  145.    received on a circuit it is assumed that:
  146.  
  147.    o  The most recently received information is accurate.
  148.  
  149.    o  The intervening path is operational (although there may be no
  150.       current connection).
  151.  
  152.    If the circuit manager determines that the intervening path is NOT
  153.    operational routing information previously received on that circuit
  154.    is timed out.  It is worth stressing that it can be ANY routed
  155.    datagram which triggers the event.
  156.  
  157.    When the circuit manager re-establishes a connection, the application
  158.    exchanges full routing information with its peer.
  159.  
  160. 3.5 Routing Information Flow Control
  161.  
  162.    If the circuit manager reports a circuit as down, the routing
  163.    application is flow controlled from sending further information on
  164.    the circuit.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Sherry & Meyer               Informational                      [Page 3]
  171.  
  172. RFC 2092            Triggered RIP Protocol Analysis         January 1997
  173.  
  174.  
  175. 4. Relationship to Demand RIP
  176.  
  177.    The Triggered RIP proposal [2] has a number of efficiency advantages
  178.    over the Demand RIP proposal [5]:
  179.  
  180.    o  When routing information changes Demand RIP sends the full
  181.       database to its partner.
  182.  
  183.       Once a router has exchanged all routing information with its
  184.       partner, Triggered RIP sends only the changed information to the
  185.       partner.  This can dramatically decrease the quantity of
  186.       information requiring propagation when a route change occurs.
  187.  
  188.    o  Demand RIP requires a full routing update to be stored by the
  189.       receiver, before applying changes to the routing database.
  190.  
  191.       A Triggered RIP receiver is able to apply all changes immediately
  192.       upon receiving each packet from its partner.  Systems therefore
  193.       need to use less memory than Demand RIP.
  194.  
  195.    o  Demand RIP has an upper limit of 255 fragments in an update.  This
  196.       sets an upper limit on the sizes of routing and service
  197.       advertising databases which can be propagated.
  198.  
  199.       This restriction is lifted in Triggered RIP (which does not use
  200.       fragmentation).
  201.  
  202.    In all other respects Demand RIP and Triggered RIP perform the same
  203.    function.
  204.  
  205. 5. Obsoleting Demand RIP
  206.  
  207.    While it is possible that systems could be able to support Demand RIP
  208.    and Triggered RIP, the internal maintenance of structures is likely
  209.    to differ significantly.  The method of propagating the information
  210.    also differs significantly.  In practice it is unlikely that systems
  211.    would support Demand RIP and Triggered RIP.
  212.  
  213.    As a result of the improved characteristics of Triggered RIP, it is
  214.    proposed that Demand RIP [5] be obsoleted.
  215.  
  216. 6. Implementations
  217.  
  218.    At this stage there are believed to be two completed implementation.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Sherry & Meyer               Informational                      [Page 4]
  227.  
  228. RFC 2092            Triggered RIP Protocol Analysis         January 1997
  229.  
  230.  
  231.    The Xyplex implementation supports all the features outlined for IP
  232.    RIP-1, IP RIP-2, IPX RIP, and IPX SAP.  However, it only supports one
  233.    outstanding acknowledgement per partner.  The implementation has been
  234.    tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs,
  235.    and asynchronous modems.  It has also been tested in operation with
  236.    various router and host implementations on Ethernet LANs.
  237.  
  238.    The DEC implementation supports IP RIP-1 over ISDN, Frame Relay,
  239.    leased lines and V.25bis.  The Xyplex and DEC IP RIP-1
  240.    implementations have been checked for interoperability over ISDN
  241.    without problems.
  242.  
  243. 7. Restrictions
  244.  
  245.    Demand RIP relies on the ability to place a call in either direction.
  246.    Some dialup services - for example DTR dialing - allow calls to be
  247.    made in one direction only.
  248.  
  249.    Demand RIP can not operate with third-party advertisement of routes
  250.    on the WAN.  The next hop IP address in RIP-2 should always be
  251.    0.0.0.0 for any routes advertised on the WAN.
  252.  
  253. 8. Security Considerations
  254.  
  255.    Security is provided through authentication of the logical and
  256.    physical address of the sender of the routing update.  Incoming call
  257.    requests are matched by the circuit manager against a list of
  258.    physical addresses (used to make outgoing calls).  The routing
  259.    application makes a further check against the logical address of an
  260.    incoming update.
  261.  
  262.    Additional security can be provided by RIP-2 authentication [2] where
  263.    appropriate.
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Sherry & Meyer               Informational                      [Page 5]
  283.  
  284. RFC 2092            Triggered RIP Protocol Analysis         January 1997
  285.  
  286.  
  287. References
  288.  
  289.    [1]  Hinden, R., "Internet Engineering Task Force Internet Routing
  290.         Protocol Standardization Criteria", RFC 1264, Bolt Beranek and
  291.         Newman, Inc, October 1991.
  292.  
  293.    [2]  Meyer. G.M. and Sherry, S., "Triggered Extensions to RIP to
  294.         Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995.
  295.  
  296.    [3]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
  297.         University, June 1988.
  298.  
  299.    [4]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
  300.         RFC 1723, Xylogics, November 1994.
  301.  
  302.    [5]  Meyer. G., "Extensions to RIP to Support Demand Circuits",
  303.         Spider Systems, February 1994.
  304.  
  305. Authors'  Address:
  306.  
  307.       Steve Sherry
  308.       Xyplex
  309.       295 Foster St.
  310.       Littleton, MA 01460
  311.  
  312.       Phone: (US) 508 952 4745
  313.       Fax:   (US) 508 952 4887
  314.       Email: shs@xyplex.com
  315.  
  316.       Gerry Meyer
  317.       Shiva Europe Ltd
  318.       Stanwell Street
  319.       Edinburgh EH6 5NG
  320.       Scotland, UK
  321.  
  322.       Phone: (UK) 131 561 4223
  323.       Fax:   (UK) 131 561 4083
  324.       Email: gerry@europe.shiva.com
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Sherry & Meyer               Informational                      [Page 6]
  339.  
  340.