home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1581.txt < prev    next >
Text File  |  1996-05-07  |  8KB  |  142 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           G. Meyer Request for Comments: 1581                                Spider Systems Category: Informational                                    February 1994 
  8.  
  9.     Protocol Analysis for Extensions to RIP to Support Demand Circuits 
  10.  
  11. Status of this Memo 
  12.  
  13.    This document provides information for the Internet community.  This    document does not specify an Internet standard of any kind.    Distribution of this document is unlimited. 
  14.  
  15. Abstract 
  16.  
  17.    As required by Routing Protocol Criteria [1], this report documents    the key features of Routing over Demand Circuits on Wide Area    Networks - RIP [2] and the current implementation experience. 
  18.  
  19. Acknowledgements 
  20.  
  21.    I would like to thank colleagues at Spider, in particular Richard    Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP    and SAP implementations. 
  22.  
  23. 1. Protocol Documents 
  24.  
  25.    "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).  Network management extensions for Demand RIP are described    in RIP Version 2 MIB Extensions [5]. 
  26.  
  27. 2. Applicability 
  28.  
  29.    Demand RIP requires that there is an underlying mechanism for    determining unreachability in a finite predictable period. 
  30.  
  31.    The demand 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: 
  32.  
  33.    o  Connection oriented Public Data Networks - for example X.25 packet       switched networks or ISDN. 
  34.  
  35.    o  Point-to-point links supporting PPP link quality monitoring or       echo request to determine link failure. 
  36.  
  37.  
  38.  
  39. Meyer                                                           [Page 1] 
  40.  RFC 1581                       Demand RIP                  February 1994 
  41.  
  42.     A demand RIP implementation runs standard RIP on Local Area Networks    (LANs) allowing them to interoperate transparently with    implementations adhering to the original specifications. 
  43.  
  44. 3. Key Features 
  45.  
  46.    The proposal shares the same basic algorithms as RIP or RIP-2 when    running on LANs or fixed point-to-point links; Packet formats,    broadcast frequency, triggered update operation and database timeouts    are all unmodified. 
  47.  
  48.    The new features operate on WANs which use switched circuits on    demand to achieve intermittent connectivity.  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. 
  49.  
  50. 3.1 Triggered Updates 
  51.  
  52.    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. 
  53.  
  54.    The packet format of a RIP response is modified (with a different    unique command field) to include sequence and fragment number    information.  An acknowledgement packet is also defined. 
  55.  
  56. 3.2 Circuit Manager 
  57.  
  58.    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. 
  59.  
  60.    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. 
  61.  
  62. 3.3 Presumption of Reachability 
  63.  
  64.    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: 
  65.  
  66.  
  67.  
  68.   
  69.  
  70. Meyer                                                           [Page 2] 
  71.  RFC 1581                       Demand RIP                  February 1994 
  72.  
  73.     o  The most recently received information is accurate. 
  74.  
  75.    o  The intervening path is operational (although there may be no       current connection). 
  76.  
  77.    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. 
  78.  
  79.    When the circuit manager re-establishes a connection, the application    exchanges full routing information with its peer. 
  80.  
  81. 3.4 Routing Information Flow Control 
  82.  
  83.    If the circuit manager reports a circuit as down, the routing    application is flow controlled from sending further information on    the circuit. 
  84.  
  85.    To prevent transmit queue overflow and also to avoid 'predictable'    circuit down messages, the routing application can also optionally    limit the rate of sending routing messages to an interface. 
  86.  
  87. 4. Implementations 
  88.  
  89.    At this stage there is only believed to be one completed    implementation. 
  90.  
  91.    The Spider Systems' implementation supports all the features outlined    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 also    been tested in operation with various router and host RIP-1, IPX RIP    and IPX SAP implementations on Ethernet LANs. 
  92.  
  93.    Two other Novell-only implementations are known to be under    development. 
  94.  
  95. 5. Restrictions 
  96.  
  97.    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. 
  98.  
  99.    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. 
  100.  
  101.  
  102.  
  103.  
  104.  
  105. Meyer                                                           [Page 3] 
  106.  RFC 1581                       Demand RIP                  February 1994 
  107.  
  108.  6. Security Considerations 
  109.  
  110.    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. 
  111.  
  112.    Additional security can be provided by RIP-2 authentication [2] where    appropriate. 
  113.  
  114. 7. References 
  115.  
  116.    [1] Hinden, R., "Internet Engineering Task Force Internet Routing        Protocol Standardization Criteria", RFC 1264, Bolt Beranek and        Newman, Inc, October 1991. 
  117.  
  118.    [2] Meyer. G., "Extensions to RIP to Support Demand Circuits", RFC        1582, Spider Systems, February 1994. 
  119.  
  120.    [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,        Rutgers University, June 1988. 
  121.  
  122.    [4] Malkin. G., "RIP Version 2 - Carrying Additional Information",        RFC 1388, Xylogics, January 1993. 
  123.  
  124.    [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC        1389, Xylogics, ACC, January 1993. 
  125.  
  126. Author's  Address 
  127.  
  128.        Gerry Meyer        Spider Systems        Stanwell Street        Edinburgh EH6 5NG        Scotland, UK 
  129.  
  130.        Phone: (UK) 31 554 9424        Fax:   (UK) 31 554 0649        EMail: gerry@spider.co.uk 
  131.  
  132.  
  133.  
  134.  
  135.  
  136.   
  137.  
  138.  
  139.  
  140. Meyer                                                           [Page 4] 
  141.  
  142.