home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-ripv2-demand-rip-00.txt < prev    next >
Text File  |  1995-03-21  |  66KB  |  1,848 lines
  1.  
  2.  
  3. Network Working Group                                         G.M. Meyer
  4. Internet Draft                                            Spider Systems
  5. Obsoletes: RFC 1582                                             Mar 1995
  6. Expires 20 Sept 1995
  7.  
  8.  
  9.               Extensions to RIP to Support Demand Circuits
  10.                       draft-ietf-demand-rip-00.txt
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is a submission to the RIP V2 Working Group of the
  16.    Internet Engineering Task Force (IETF).  Comments should be submitted
  17.    to the ietf-rip@xylogics.com mailing list.
  18.  
  19.    Distribution of this memo is unlimited.
  20.  
  21.    This document is an Internet-Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups.  Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months, and may be updated, replaced, or obsoleted by other documents
  28.    at any time.  It is not appropriate to use Internet Drafts as
  29.    reference material, or to cite them other than as a ``working draft''
  30.    or ``work in progress.''
  31.  
  32.    To learn the current status of any Internet-Draft, please check the
  33.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  34.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  35.    Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  36.  
  37. Abstract
  38.  
  39.    Running routing protocols on connection oriented Public Data
  40.    Networks, for example X.25 packet switched networks or ISDN, can be
  41.    expensive if the standard form of periodic broadcasting of routing
  42.    information is adhered to.  The high cost arises because a connection
  43.    has to all practical intents and purposes be kept open to every
  44.    destination to which routing information is to be sent, whether or
  45.    not it is being used to carry user data.
  46.  
  47.    Routing information may also fail to be propagated if the number of
  48.    destinations to which the routing information is to be sent exceeds
  49.    the number of channels available to the router on the Wide Area
  50.    Network (WAN).
  51.  
  52.  
  53.  
  54. Meyer                                                           [Page 1]
  55.  
  56. Internet Draft                 Demand RIP                       Mar 1995
  57.  
  58.  
  59.    This memo defines a generalised modification which can be applied to
  60.    Bellman-Ford (or distance vector) algorithm information broadcasting
  61.    protocols, for example IP RIP, Netware RIP or Netware SAP, which
  62.    overcomes the limitations of the traditional methods described above.
  63.    The routing protocols support a purely triggered update mechanism on
  64.    demand circuits on WANs.  The protocols run UNMODIFIED on LANs; and
  65.    may also run unmodified on fixed point-to-point links.
  66.  
  67.    Routing information is sent on the WAN when the routing database is
  68.    modified by new routing information received from another interface.
  69.    When this happens a (triggered) update is sent to a list of
  70.    destinations on other WAN interfaces.  Because routing protocols are
  71.    datagram based they are not guaranteed to be received by the peer
  72.    router on the WAN.  An acknowledgement and retransmission mechanism
  73.    is provided to ensure that routing updates are received.
  74.  
  75.    The WAN circuit manager advises the routing applications on the
  76.    reachability and non-reachability of destinations on the WAN.
  77.  
  78. Acknowledgements
  79.  
  80.    I would like to thank colleagues at Spider, in particular Richard
  81.    Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM), Martha
  82.    Steenstrup (BBN), and members of the RIP-2 work group of the IETF for
  83.    stimulating discussions and comments which helped to clarify this
  84.    memo.
  85.  
  86. Conventions
  87.  
  88.    The following language conventions are used in the items of
  89.    specification in this document:
  90.  
  91.    o  MUST -- the item is an absolute requirement of the specification.
  92.       MUST is only used where it is actually required for interopera-
  93.       tion, not to try to impose a particular method on implementors
  94.       where not required for interoperability.
  95.  
  96.    o  SHOULD -- the item should be followed for all but exceptional cir-
  97.       cumstances.
  98.  
  99.    o  MAY or optional -- the item is truly optional and may be followed
  100.       or ignored according to the needs of the implementor.
  101.  
  102.       The words "should" and "may" are also used, in lower case, in
  103.       their more ordinary senses.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Meyer                                                           [Page 2]
  111.  
  112. Internet Draft                 Demand RIP                       Mar 1995
  113.  
  114.  
  115.  
  116.                           Table of Contents
  117.  
  118.       1. Introduction ...........................................  4
  119.  
  120.       2. Running a routing Protocol on the WAN ..................  6
  121.           2.1. Overview .........................................  6
  122.           2.2. Presumption of Reachability ......................  8
  123.           2.3. WAN Router list ..................................  8
  124.           2.4. Triggered Updates and Unreliable Delivery ........  9
  125.           2.5. Guaranteeing delivery of Routing Updates .........  9
  126.           2.6. The Routing Database ............................. 10
  127.           2.7. New Packet Types ................................. 11
  128.           2.8. Fragmentation .................................... 13
  129.           2.9. Preventing Queue Overload ........................ 14
  130.  
  131.       3. IP Routing Information Protocol Version 1 .............. 16
  132.  
  133.       4. IP Routing Information Protocol Version 2 .............. 19
  134.  
  135.       5. Netware Routing Information Protocol ................... 20
  136.  
  137.       6. Netware Service Advertising Protocol ................... 24
  138.  
  139.       7. Timers ................................................. 28
  140.           7.1. Database Timer ................................... 28
  141.           7.2. Retransmission Timer ............................. 29
  142.           7.3. Reassembly Timer ................................. 30
  143.  
  144.       8. Implementation Considerations ...........................31
  145.  
  146.       9. Security Considerations ................................ 32
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Meyer                                                           [Page 3]
  167.  
  168. Internet Draft                 Demand RIP                       Mar 1995
  169.  
  170.  
  171. 1. Introduction
  172.  
  173.    Routers are used on connection oriented networks, such as X.25 packet
  174.    switched networks and ISDN networks, to allow potential connectivity
  175.    to a large number of remote destinations.  Circuits on the Wide Area
  176.    Network (WAN) are established on demand and are relinquished when the
  177.    traffic subsides.  Depending on the application, the connection
  178.    between any two sites for user data might actually be short and rela-
  179.    tively infrequent.
  180.  
  181.    Practical experience of routing shows that periodic 'broadcasting' of
  182.    routing updates on the WAN is unsatisfactory on several counts:
  183.  
  184.    o  Running a routing protocol like RIP is expensive if the standard
  185.       form of transmitting routing information to every next hop router
  186.       every 30 seconds is adhered to.  The more routers there are wish-
  187.       ing to exchange information the worse the problem.  If there are N
  188.       routers on the WAN, N * (N - 1) routing updates are sent over N *
  189.       (N - 1)/2 connections every broadcast period.
  190.  
  191.       The expense arises because a circuit has to be kept open to each
  192.       destination to which routing information is to be sent.  Routing
  193.       updates are sufficiently frequent that little benefit is obtain-
  194.       able on most networks by attempting to set up a call purely for
  195.       the duration of the routing update. (There are often minimum call
  196.       charges, or there is a charge to set up a call irrespective of
  197.       what data is sent.)
  198.  
  199.       The option of reducing the 'broadcast' frequency, while reducing
  200.       the cost, would make the system less responsive.
  201.  
  202.    o  The number of networks to be connected (N) on the WAN can easily
  203.       exceed the number of simultaneous calls (M) which the interface
  204.       can support.  If this happens the routing 'broadcast' will only
  205.       reach M next hop routers, and (N - M) next hop routers will not
  206.       receive the routing update.
  207.  
  208.       A basic rate ISDN interface can support 2 simultaneous calls, and
  209.       even the number of logical channels most users subscribe to on an
  210.       X.25 network is not large.  There is no fundamental reason why
  211.       routing protocols should restrict the user to routing between so
  212.       few sites.
  213.  
  214.    o  Since there is no broadcast facility on the WAN, 'broadcasting' of
  215.       routing information actually consists of sending the updates
  216.       separately to all known locations.  This means that N routing
  217.       updates are queued for transmission on the WAN link (in addition
  218.       to any data which might be queued).
  219.  
  220.  
  221.  
  222. Meyer                                                           [Page 4]
  223.  
  224. Internet Draft                 Demand RIP                       Mar 1995
  225.  
  226.  
  227.       Routers take a pragmatic view on queuing datagrams for the WAN.
  228.       If the queue length gets too long, so that datagrams at the end of
  229.       the queue would take too long be transmitted in a reasonable time
  230.       (say 1 to 2 seconds) the router may start discarding them.  On an
  231.       X.25 network, with slow line speeds (perhaps 9600 baud), it may
  232.       not take too many routing updates to fulfill this condition if the
  233.       link is also actively being used to carry user data.
  234.  
  235.    o  Even on fixed point-to-point links the overhead of periodic
  236.       transmission of RIP - and even more so SAP broadcasts - can seri-
  237.       ously interrupt normal data transfer simply through the quantity
  238.       of information which hits the line every 30 or 60 seconds.
  239.  
  240.    This memo addresses all the above problems.
  241.  
  242.    The approach taken is to modify the routing protocols so as to send
  243.    information on the WAN only when there has been an update to the
  244.    routing database OR a change in the reachability of a next hop router
  245.    is indicated by the task which manages connections on the WAN.
  246.  
  247.    Because datagrams are not guaranteed to get through on all WAN media,
  248.    an acknowledgement and retransmission system is required to provide
  249.    reliability.
  250.  
  251.    This memo describes the modifications required for Bellman-Ford (or
  252.    distance vector) algorithm information broadcasting protocols, such
  253.    as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN.  The protocols
  254.    run unmodified on Local Area Networks (LANs) - and may also run unmo-
  255.    dified on fixed point-to-point links - and so interoperate tran-
  256.    sparently with implementations adhering to the original specifica-
  257.    tions.
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Meyer                                                           [Page 5]
  279.  
  280. Internet Draft                 Demand RIP                       Mar 1995
  281.  
  282.  
  283. 2. Running Routing Protocols on the WAN
  284.  
  285. 2.1 Overview
  286.  
  287.    Multiprotocol routers are used on connection oriented Wide Area Net-
  288.    works (WANs), such as X.25 packet switched networks and ISDN net-
  289.    works, to interconnect LANs.  By using the multiplexing properties of
  290.    the underlying WAN technology, several LANs can be interconnected
  291.    simultaneously through a single physical interface on the router.
  292.  
  293.    A circuit manager provides an interface between the connectionless
  294.    network layers, IP and IPX, and the connection oriented WAN, X.25,
  295.    ISDN etc.  Figure 1 shows a schematic representative stack showing
  296.    the relationship between routing protocols, the network layers, the
  297.    circuit manager and the connection oriented WAN.
  298.  
  299.  
  300.              --------------           ---------  ---------
  301.              |    RIP     |           |  RIP  |  |  SAP  |
  302.              --------------           ---------  ---------
  303.                    |                      |          |
  304.              --------------               |          |
  305.              |    UDP     |               |          |
  306.              --------------               |          |
  307.                    |                      |          |
  308.              --------------             ----------------
  309.              |    IP      |             |     IPX      |
  310.              --------------             ----------------
  311.                    |                           |
  312.              -------------------------------------------
  313.              |             Circuit Manager             |
  314.              -------------------------------------------
  315.                               ||||||||||
  316.                               ||||||||||
  317.                       ---------------------------
  318.                       |   Connection Oriented   |
  319.                       |        WAN stack        |
  320.                       ---------------------------
  321.  
  322.      A WAN circuit manager will  support  a  variety  of  network  layer
  323.      protocols,  on its upper interface.  On its lower interface, it may
  324.      support one or more subnetworks.  A subnetwork may support a number
  325.      of Virtual Circuits.
  326.  
  327.  
  328.             Figure 1.   Representative Multiprotocol Router stack
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Meyer                                                           [Page 6]
  335.  
  336. Internet Draft                 Demand RIP                       Mar 1995
  337.  
  338.  
  339.    The router has a translation table which relates the network layer
  340.    address of the next hop router to the physical address used to estab-
  341.    lish a Virtual Circuit (VC) to it.  Datagrams may be encapsulated in
  342.    a header to distinguish the network layer protocol [5].
  343.  
  344.    The circuit manager takes datagrams from the connectionless network
  345.    layer protocols and (if one is not currently available) opens a VC to
  346.    the next hop router.  A VC can carry all traffic between two end-
  347.    point routers for a given network layer protocol (or with appropriate
  348.    encapsulation all network layer protocols).  An idle timer is used to
  349.    close the VC when the datagrams stop arriving at the circuit manager.
  350.  
  351.    Running routing protocols on the WAN has traditionally consisted of
  352.    making small modifications to the methods used on LANs.  Where rout-
  353.    ing information would be broadcast periodically on a LAN interface,
  354.    it is converted to a series of periodic updates sent to a list of
  355.    addresses on the WAN.
  356.  
  357.    This memo targets two areas:
  358.  
  359.    o  Eliminating the overkill inherent in periodic transmission of
  360.       routing updates.
  361.  
  362.    o  Overcoming the bandwidth limitations on the WAN:  the number of
  363.       simultaneous VCs to next hop routers and the restricted data
  364.       throughput which the WAN link can support.
  365.  
  366.    The first of these is overcome by transmitting routing updates
  367.    (called routing responses) only when required:
  368.  
  369.    o  Firstly when a specific request for a routing update has been
  370.       received.
  371.  
  372.    o  Secondly when the routing database is modified by new information
  373.       from another interface.
  374.  
  375.       Update information received in this way is not normally propagated
  376.       on other interfaces immediately, but is delayed for a few seconds
  377.       to allow information from several updates to be grouped.
  378.  
  379.    o  Thirdly when the circuit manager indicates that a destination has
  380.       changed from an unreachable (circuit down) to a reachable (circuit
  381.       up) state.
  382.  
  383.    o  And also when a unit is first powered on to ensure that at least
  384.       one update is sent.  This can be thought of as a transition from
  385.       circuit down to circuit up.  It MAY contain no routes or services,
  386.       and is used to flush routes or services from the peer's database.
  387.  
  388.  
  389.  
  390. Meyer                                                           [Page 7]
  391.  
  392. Internet Draft                 Demand RIP                       Mar 1995
  393.  
  394.  
  395.    In ALL cases the COMPLETE routing database is transmitted - using
  396.    split horizon rules, namely everything NOT learned from that inter-
  397.    face.
  398.  
  399.    Because of the inherent unreliability of a datagram based system,
  400.    both routing requests and routing responses require acknowledgement,
  401.    and retransmission in the event of NOT receiving an acknowledgement.
  402.  
  403.    To overcome the bandwidth limitations the routing application can
  404.    perform a form of self-imposed flow control, to spread routing
  405.    updates out over a period of time.
  406.  
  407. 2.2 Presumption of Reachability
  408.  
  409.    If a routing update is received from a next hop router on the WAN,
  410.    entries in the update are thereafter always considered to be reach-
  411.    able, unless proven otherwise:
  412.  
  413.    o  If in the normal course of routing datagrams, the circuit manager
  414.       fails to establish a connection to the next hop router, it noti-
  415.       fies the routing application that the next hop router is not
  416.       reachable through an internal circuit down message.
  417.  
  418.       The routing application then goes through a process of timing out
  419.       database entries to make them unreachable in the routing sense.
  420.  
  421.    o  If the circuit manager is subsequently able to establish a connec-
  422.       tion to the next hop router, it will notify the routing applica-
  423.       tion that the next hop router is reachable through an internal
  424.       circuit up message.
  425.  
  426.       The routing application will then exchange messages with the next
  427.       hop router so as to re-prime their respective routing databases
  428.       with up-to-date information.
  429.  
  430.    Handling of circuit up and circuit down messages requires that the
  431.    circuit manager takes responsibility for establishing (or re-
  432.    establishing) the connection in the event of a next hop router becom-
  433.    ing unreachable.  A description of the processes the circuit manager
  434.    adopts to perform this task is outside the scope of this memo.
  435.  
  436. 2.3 WAN Router list
  437.  
  438.    The routing task MAY be provided with a list of routers to send rout-
  439.    ing updates to on the WAN.  It will comprise of the logical addresses
  440.    of next hop routers for which the router has a logical to physical
  441.    address mapping.  Entries in the list SHOULD be categorised (on a
  442.    per-peer basis) as follows:
  443.  
  444.  
  445.  
  446. Meyer                                                           [Page 8]
  447.  
  448. Internet Draft                 Demand RIP                       Mar 1995
  449.  
  450.  
  451.    o  Running the standard routing protocol, namely transmitting updates
  452.       periodically with the packet formats used in LAN broadcasts.
  453.  
  454.       This option is supported to allow interoperability with existing
  455.       routing implementations, and might also be appropriate if some of
  456.       the destinations are using Permanent Virtual Circuits (PVCs)
  457.       rather than SVCs.
  458.  
  459.    o  Running the triggered update routing protocol proposed in this
  460.       memo.
  461.  
  462.    Omitting an address from both of these categories is equivalent to
  463.    not running the routing protocols.
  464.  
  465.    If routing packets arrive from a destination not supporting the
  466.    appropriate variant they MUST be discarded.
  467.  
  468. 2.4 Triggered Updates and Unreliable Delivery
  469.  
  470.    If triggered update information is sent to next hop routers on the
  471.    WAN only once it can fail to arrive for one of the following reasons:
  472.  
  473.    o  A free VC resource might not be available, because of a restricted
  474.       number of X.25 logical channels or ISDN B-channels.
  475.  
  476.    o  The transmit queue might be full - requiring the datagram to be
  477.       discarded.
  478.  
  479.    o  The VC might be pre-empted (in favour of establishing a VC to
  480.       another next hop router) while the datagram is in a queue, result-
  481.       ing in the queue being flushed and the datagram discarded.
  482.  
  483.    o  In cases where the method of transport is not guaranteed, for
  484.       example with PPP where there is no acknowledgement and retransmis-
  485.       sion of HDLC frames, a corrupted frame will result in the loss of
  486.       the datagram.
  487.  
  488. 2.5 Guaranteeing delivery of Routing Updates
  489.  
  490.    To guarantee delivery of routing updates on the WAN an acknowledge-
  491.    ment and retransmission scheme MUST be used:
  492.  
  493.    o  Send a routing update to a next hop router on the WAN.
  494.  
  495.    o  The other router responds with an acknowledgement packet.
  496.  
  497.       The original router receives the acknowledgement.
  498.  
  499.  
  500.  
  501.  
  502. Meyer                                                           [Page 9]
  503.  
  504. Internet Draft                 Demand RIP                       Mar 1995
  505.  
  506.  
  507.    o  Otherwise the original router retransmits the update until an ack-
  508.       nowledgement is received.
  509.  
  510.       Retransmission timer values are covered in section 7.
  511.  
  512.       In cases where the routing database is modified before an ack-
  513.       nowledgement is received a new routing update with an updated
  514.       sequence number is sent out.  If an acknowledgement for the old
  515.       routing update is received it is ignored.
  516.  
  517.    o  A router only updates its routing database when it receives a com-
  518.       plete update, which may consist of several fragments.  Each frag-
  519.       ment is individually acknowledged.
  520.  
  521.    The above mechanism caters for cases where the datagram is lost
  522.    because of a frame error or is discarded because of an over-full
  523.    queue.  The routing update and acknowledgement will eventually both
  524.    get through.
  525.  
  526.    In cases where the circuit manager cannot establish a connection, a
  527.    mechanism is provided to allow the circuit manager to inform the
  528.    routing task of the failure to make a connection so that it can
  529.    suppress retransmissions until a circuit becomes available.
  530.  
  531. 2.6 The Routing Database
  532.  
  533.    A requirement of using triggered updates for propagating routing
  534.    information is that NO routing information ever gets LOST or DIS-
  535.    CARDED.
  536.  
  537.    The routing database MUST adopt one of the following strategies:
  538.  
  539.    o  It must keep ALL alternative routing information it learns from
  540.       any routing updates from the LAN and the WAN, so that if the best
  541.       route disappears an alternative route (if available) can replace
  542.       it as the new best route.
  543.  
  544.    o  If the amount of memory this consumes is problematic the routing
  545.       application must keep SOME alternative routing information - say a
  546.       best route and two alternatives.
  547.  
  548.       If the router ever has to discard routing information about a
  549.       route it should note the fact.   If the routes that have been kept
  550.       disappear because they have become unreachable, the router MUST
  551.       issue a request on all interfaces to try and obtain discarded
  552.       alternatives.
  553.  
  554.       It is recommended that the request is issued BEFORE all routes to
  555.  
  556.  
  557.  
  558. Meyer                                                          [Page 10]
  559.  
  560. Internet Draft                 Demand RIP                       Mar 1995
  561.  
  562.  
  563.       a destination have been lost.
  564.  
  565.    Entries in the routing database can either be permanent or temporary.
  566.    Entries learned from broadcasts on LANs are temporary. They will
  567.    expire if not periodically refreshed by further broadcasts.
  568.  
  569.    Entries learned from a triggered response on the WAN are 'permanent'.
  570.    They MUST not time out in the normal course of events.  The entries
  571.    state MUST be changed to 'temporary' by the following events:
  572.  
  573.    o  The arrival of a routing update containing the entry set to
  574.       unreachable.
  575.  
  576.       The normal hold down timer MUST be started, after which the entry
  577.       disappears from the routing database.
  578.  
  579.    o  The arrival of a routing update with the entry absent.
  580.  
  581.       If the hold down timer is not already running, the entry MUST be
  582.       set to unreachable and the hold down timer started.
  583.  
  584.    o  A message sent from the circuit manager, to indicate that it
  585.       failed to make a connection in normal running.
  586.  
  587.       The routing table MUST be scanned for all routes via that next hop
  588.       router.  Aging of these routing entries MUST commence.  If the
  589.       aging timer expires the entry MUST be set to unreachable and the
  590.       hold down timer started.  If the hold down timer expires the entry
  591.       disappears from the routing database.
  592.  
  593.    o  If the interface goes down, the circuit manager should indicate
  594.       that all circuits on that interface have gone down.
  595.  
  596.    Database timer values are covered in section 7.
  597.  
  598. 2.7 New Packet Types
  599.  
  600.    To support triggered updates, three new packet types MUST be sup-
  601.    ported:
  602.  
  603.    TRIGGERED REQUEST
  604.  
  605.              A request to the responding system to send all appropriate
  606.              elements in its routing database.
  607.  
  608.              A triggered request is retransmitted at periodic intervals
  609.              until a triggered response is received.
  610.  
  611.  
  612.  
  613.  
  614. Meyer                                                          [Page 11]
  615.  
  616. Internet Draft                 Demand RIP                       Mar 1995
  617.  
  618.  
  619.              Routing requests are transmitted in the following cir-
  620.              cumstances:
  621.  
  622.              o  Firstly when the router is powered on.
  623.  
  624.              o  Secondly when the circuit manager indicates a destina-
  625.                 tion has been in an unreachable (circuit down) state for
  626.                 an extended period and changes to a reachable (circuit
  627.                 up) state.
  628.  
  629.              o  Thirdly in the event of all routing update fragments
  630.                 failing to arrive within a set period.
  631.  
  632.              o  It may also send triggered requests at other times to
  633.                 compensate for discarding non-optimal routing informa-
  634.                 tion.
  635.  
  636.    TRIGGERED RESPONSE
  637.  
  638.              A message containing all appropriate elements of the rout-
  639.              ing database.  An appropriate element is an entry NOT
  640.              learned from the interface to which the routing information
  641.              is being sent out.  This is known as "split horizon".
  642.  
  643.              Stability is improved by adding "poisoned reverse" on
  644.              routes learned from a destination.  This consists of also
  645.              including some routes learned from a destination in routing
  646.              updates sent back to that destination, but setting the
  647.              routes as unreachable.  A route is only poisoned if it is
  648.              the best route (rather than an inferior alternative route)
  649.              in the database.
  650.  
  651.              A triggered response message MUST be sent:
  652.  
  653.              o  In response to a triggered request,
  654.  
  655.              o  As an update message issued because of a change in the
  656.                 routing database.
  657.  
  658.              o  And also at power on to flush the peers routing table
  659.                 learned from a previous incarnation.  This guards
  660.                 against the case where in the old life routes or ser-
  661.                 vices were present, but there are none in the new life
  662.                 to trigger a response.
  663.  
  664.       A triggered response message MUST be sent in response to a trig-
  665.       gered request message even if there are no routes to propagate.
  666.       This would be the case for a host which had a WAN interface only,
  667.  
  668.  
  669.  
  670. Meyer                                                          [Page 12]
  671.  
  672. Internet Draft                 Demand RIP                       Mar 1995
  673.  
  674.  
  675.       but which wished to run the triggered update protocol.
  676.  
  677.       A triggered response is retransmitted at periodic intervals until
  678.       a triggered acknowledgement is received.
  679.  
  680.    TRIGGERED ACKNOWLEDGEMENT
  681.  
  682.              A message sent in response to every triggered response
  683.              packet received.
  684.  
  685.    Triggered response and triggered acknowledgement packets MUST contain
  686.    additional fields for a sequence number, fragment number and number
  687.    of fragments.
  688.  
  689.    If a triggered request or response is not acknowledged after 10
  690.    retransmissions, routes to the destination should be marked as
  691.    unreachable for the duration of a hold down timer before being
  692.    deleted.
  693.  
  694.    The destination should then be polled at a lower frequency using
  695.    triggered request packets.  When a triggered response is received,
  696.    the router should prime the next hop router my sending its routing
  697.    database through triggered response packets.
  698.  
  699.    Strictly speaking polling should occur indefinitely to guarantee
  700.    database integrity.  However the administrator MAY wish the router to
  701.    cease polling after a few attempts believing that the lack of
  702.    response is due to a mis-configuration of the next hop router.  The
  703.    destination should be marked as NOT supporting the mechanism and no
  704.    further routing messages should be sent to that destination.
  705.  
  706.    Before marking the destination as not supporting the mechanism, at
  707.    least 5 triggered request polls (without acknowledgement) should be
  708.    sent.
  709.  
  710.    If a destination marked as not supporting the mechanism, subsequently
  711.    sends a valid 'triggered' message, the destination should be marked
  712.    as supporting the mechanism once more (to allow for the next hop
  713.    router's configuration being changed).  It should be sent a triggered
  714.    request and a triggered response to obtain and propagate up-to-date
  715.    routing information.
  716.  
  717. 2.8 Fragmentation
  718.  
  719.    If a routing update is sufficiently large, the information MUST be
  720.    fragmented over several triggered response packets:
  721.  
  722.    o  Each fragment MUST be individually acknowledged with a triggered
  723.  
  724.  
  725.  
  726. Meyer                                                          [Page 13]
  727.  
  728. Internet Draft                 Demand RIP                       Mar 1995
  729.  
  730.  
  731.       acknowledgement packet.
  732.  
  733.       The sender of the routing update MUST periodically retransmit
  734.       fragments which have not been acknowledged (or until the destina-
  735.       tion is marked as not supporting the mechanism).
  736.  
  737.    o  A router receiving fragments MUST re-assemble them before updating
  738.       its routing database.
  739.  
  740.    o  If all fragments are not received within four times the retransmit
  741.       period, they MUST be discarded.
  742.  
  743.       A triggered request packet MUST then be sent to the originator of
  744.       the routing update.
  745.  
  746.       On receiving the triggered request packet, the originator of the
  747.       routing update MUST retransmit ALL fragments.
  748.  
  749.    o  If a fragment with an updated sequence number is received, ALL
  750.       fragments with the earlier sequence number MUST be discarded.
  751.  
  752.       An updated sequence number is defined as any sequence number that
  753.       is different.  There is no concept of the value of the sequence
  754.       number conveying its age.
  755.  
  756.    Fragmentation timer values are covered in section 7.
  757.  
  758. 2.9 Preventing Queue Overload
  759.  
  760.    In order to prevent too many routing messages being queued at a WAN
  761.    interface, the routing task MAY operate a scheme whereby 'broadcast-
  762.    ing' of a triggered request or triggered response to a WAN interface
  763.    is staggered.  All routing requests or routing responses are not sent
  764.    to ALL next hop routers on the interface in a single batch:
  765.  
  766.    o  The routing task should limit the number of outstanding triggered
  767.       request messages for which a triggered response has not been
  768.       received.
  769.  
  770.    o  The routing task should limit the number of outstanding triggered
  771.       response messages for which a triggered acknowledgement has not
  772.       been received.
  773.  
  774.    As outstanding messages are appropriately acknowledged, further mes-
  775.    sages can be sent out to other next hop routers, until all next hop
  776.    routers have been sent the message and have acknowledged it.
  777.  
  778.    The maximum number of outstanding messages transmitted without
  779.  
  780.  
  781.  
  782. Meyer                                                          [Page 14]
  783.  
  784. Internet Draft                 Demand RIP                       Mar 1995
  785.  
  786.  
  787.    acknowledgement is a function of the link speed and the number of
  788.    other routing protocols operating the triggered update mechanism.
  789.  
  790.    Messages should always be acknowledged immediately (even if it causes
  791.    the limit to be exceeded), since a connection is almost certainly
  792.    available.  This has the potential benefit of allowing the VC to
  793.    close sooner (on its idle timer).
  794.  
  795.    Sending all triggered request fragments to a destination at once is
  796.    also beneficial.
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838. Meyer                                                          [Page 15]
  839.  
  840. Internet Draft                 Demand RIP                       Mar 1995
  841.  
  842.  
  843. 3. IP Routing Information Protocol Version 1
  844.  
  845.    This section should be read in conjunction with reference [1].
  846.  
  847.    IP RIP is a UDP-based protocol which generally sends and receives
  848.    datagrams on UDP port number 520.
  849.  
  850.    To support the mechanism outlined in this proposal the packet format
  851.    for RIP version 1 [1] is modified as shown in Figure 2.
  852.  
  853.    Every Routing Information Protocol datagram contains the following:
  854.  
  855.    COMMAND   Commands supported in RIP Version 1 are: request (1),
  856.              response (2), traceon (3), traceoff (4), SUN reserved (5).
  857.              The fields sequence number, fragment number and number of
  858.              fragments MUST NOT be included in packets with these com-
  859.              mand values.
  860.  
  861.              The following new commands (with values in brackets) are
  862.              required:
  863.  
  864.        TRIGGERED REQUEST (6)
  865.  
  866.                  A request for the responding system to send all of its
  867.                  routing database.
  868.  
  869.                  Only the first 4 octets of the packet format shown in
  870.                  figure 2 are sent, since all routing information is
  871.                  implied by this request type.  Any additional octets
  872.                  received should be ignored.
  873.  
  874.        TRIGGERED RESPONSE (7)
  875.  
  876.                  A message containing all of the sender's routing data-
  877.                  base, excluding those entries learned from the inter-
  878.                  face to which the routing information is being sent.
  879.  
  880.                  This message is sent in response to a triggered
  881.                  request, or as a result of a change in the routing
  882.                  database.  A triggered response MUST be sent at power
  883.                  up.
  884.  
  885.                  A triggered response message MUST be sent in response
  886.                  to a triggered request message even if there are no
  887.                  routes to propagate.  This would be the case for a host
  888.                  which had a WAN interface only, but which wished to run
  889.                  the triggered update protocol.
  890.  
  891.  
  892.  
  893.  
  894. Meyer                                                          [Page 16]
  895.  
  896. Internet Draft                 Demand RIP                       Mar 1995
  897.  
  898.  
  899.  
  900.      0                   1                   2                   3 3
  901.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  902.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  903.      | command (1)   | version (1)   |      must be zero (2)         |
  904.      +---------------+---------------+-------------------------------+
  905.  
  906.         The following new fields are inserted for some commands
  907.  
  908.      0                   1                   2                   3 3
  909.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  910.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  911.      |    sequence number (2)        | fragment (1)  |no of frags (1)|
  912.      +-------------------------------+-------------------------------+
  913.  
  914.           Followed by up to 25 routing entries (each 20 octets)
  915.  
  916.      0                   1                   2                   3 3
  917.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  918.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  919.      | address family identifier (2) |      must be zero (2)         |
  920.      +-------------------------------+-------------------------------+
  921.      |                         IP address (4)                        |
  922.      +---------------------------------------------------------------+
  923.      |                        must be zero (4)                       |
  924.      +---------------------------------------------------------------+
  925.      |                        must be zero (4)                       |
  926.      +---------------------------------------------------------------+
  927.      |                          metric (4)                           |
  928.      +---------------------------------------------------------------+
  929.                                      .
  930.                                      .
  931.  
  932.      The format of an IP RIP datagram in octets,  with  each  tick  mark
  933.      representing one bit.    All fields are in network order.
  934.  
  935.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  936.      number  of  fragments  (1)  are  not  present  in  the original RIP
  937.      specification.   They are only present if command takes the  values
  938.      7 or 8.
  939.  
  940.  
  941.           Figure 2.   IP Routing Information Protocol packet format
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950. Meyer                                                          [Page 17]
  951.  
  952. Internet Draft                 Demand RIP                       Mar 1995
  953.  
  954.  
  955.        TRIGGERED ACKNOWLEDGEMENT (8)
  956.  
  957.                  A message sent in response to every triggered response
  958.                  packet received.
  959.  
  960.                  Only the first 8 octets of the packet format shown in
  961.                  figure 2 are sent.
  962.  
  963.    VERSION   In this instance Version 1.
  964.  
  965.    SEQUENCE NUMBER
  966.  
  967.              This is a new field inserted if command takes the values 7
  968.              or 8.
  969.  
  970.              The sequence number MUST be incremented every time updated
  971.              information is sent out on a WAN.  The sequence number
  972.              wraps round at 65535.
  973.  
  974.              When a triggered acknowledgement is sent the sequence
  975.              number is set to the same value as the triggered response
  976.              packet being acknowledged.
  977.  
  978.              The sequence number MUST be identical over fragments.  If a
  979.              fragment is retransmitted the sequence number MUST not
  980.              change.
  981.  
  982.    FRAGMENT NUMBER
  983.  
  984.              The fragment number is one for the first fragment of a
  985.              routing update, and is incremented for each subsequent
  986.              fragment.  A fragment can contain up to 25 routing entries.
  987.  
  988.              When a triggered acknowledgement is sent the fragment
  989.              number is set to the same value as the triggered response
  990.              packet being acknowledged.
  991.  
  992.    NUMBER OF FRAGMENTS
  993.  
  994.              In a triggered response packet this indicates the number of
  995.              packets required to complete the routing update.
  996.  
  997.              This field has no relevance for triggered acknowledgement
  998.              packets so should be set to zero.
  999.  
  1000.    For triggered response packets the rest of the datagram contains a
  1001.    list of destinations, with information about each.  Each entry in
  1002.    this list contains the address family identifier (2 for IP), a
  1003.  
  1004.  
  1005.  
  1006. Meyer                                                          [Page 18]
  1007.  
  1008. Internet Draft                 Demand RIP                       Mar 1995
  1009.  
  1010.  
  1011.    destination network or host, and the metric for it.  The packet for-
  1012.    mat is intended to allow RIP to carry routing information  for
  1013.    several different protocols, identifiable by the family identifier.
  1014.  
  1015.    The IP address is the usual Internet address, stored as 4 octets in
  1016.    network order.  The metric field contains a value between 1 and 15
  1017.    inclusive, specifying the current metric for the destination, or the
  1018.    value 16 (representing 'infinity'), which indicates that the destina-
  1019.    tion is not reachable.  Each route sent by a router supersedes any
  1020.    previous route to the same destination from the same router.
  1021.  
  1022.    The maximum datagram size is 508 octets, excluding UDP and IP
  1023.    headers.
  1024.  
  1025. 4. IP Routing Information Protocol Version 2
  1026.  
  1027.    RIP-2 [2] is an enhancement to IP RIP Version 1 [1] which allows RIP
  1028.    updates to include subnetting information.  This section only
  1029.    describes differences from that RFC.
  1030.  
  1031.    The triggered update mechanism can be supported by including the
  1032.    triggered request (6), triggered response (7) and triggered ack-
  1033.    nowledgement (8) commands described in the previous section.
  1034.  
  1035.    The sequence number, fragment number and number of fragments fields
  1036.    are included in triggered response and triggered acknowledgement com-
  1037.    mands.
  1038.  
  1039.    The triggered request packet should also contain the 4 extra octets
  1040.    corresponding to the sequence number, fragment number and number of
  1041.    fragments fields - but set to zero.
  1042.  
  1043.    Because additional security information is included in RIP Version 2
  1044.    packets, this MUST be appended to the triggered request and triggered
  1045.    acknowledgement packets, as well as being present in the triggered
  1046.    response packet.
  1047.  
  1048.    The version number becomes 2.  Other aspects of packet layout follow
  1049.    reference [2].
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062. Meyer                                                          [Page 19]
  1063.  
  1064. Internet Draft                 Demand RIP                       Mar 1995
  1065.  
  1066.  
  1067. 5. Netware Routing Information Protocol
  1068.  
  1069.    This section should be read in conjunction with references [3], since
  1070.    it only describes differences from the specification.
  1071.  
  1072.    Netware [3] is the trade name of Novell Research's protocols for com-
  1073.    puter communication which are derived and extended from Xerox Network
  1074.    System's (XNS) protocols [4].
  1075.  
  1076.    Netware supports a mechanism that allows routers on an internetwork
  1077.    to exchange routing information using the Routing Information Proto-
  1078.    col (RIP) which runs over the Internetwork Packet Exchange (IPX) pro-
  1079.    tocol using socket number 453h.
  1080.  
  1081.    Netware RIP and IP RIP share a common heritage, in that they are both
  1082.    based on XNS RIP, but there is some divergence, mostly at the packet
  1083.    format level to reflect the differing addressing schemes.
  1084.  
  1085.    The triggered update mechanism can be applied to Netware RIP.  To
  1086.    support the mechanism outlined in this proposal the packet format for
  1087.    Netware RIP is modified as shown in Figure 3.
  1088.  
  1089.    Every datagram contains the following:
  1090.  
  1091.    RIP OPERATION
  1092.  
  1093.              Operations supported in standard Netware RIP are: request
  1094.              (1) and response (2).
  1095.  
  1096.              The fields sequence number, fragment number and number of
  1097.              fragments MUST NOT be included in packets with these opera-
  1098.              tion values.
  1099.  
  1100.              The following new operations are required (with values
  1101.              chosen to be the same as for IP RIP commands):
  1102.  
  1103.        TRIGGERED REQUEST (6)
  1104.  
  1105.                  A request for the responding system to send all of its
  1106.                  routing database.
  1107.  
  1108.                  Only the first 2 octets of the packet format shown in
  1109.                  figure 3 are sent, since all routing information is
  1110.                  implied by this request type.  Any additional octets
  1111.                  received should be ignored.
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118. Meyer                                                          [Page 20]
  1119.  
  1120. Internet Draft                 Demand RIP                       Mar 1995
  1121.  
  1122.  
  1123.  
  1124.      0                   1         1
  1125.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1126.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1127.      |       operation (2)           |
  1128.      +---------------+---------------+
  1129.  
  1130.         The following new fields are inserted for some operations
  1131.  
  1132.      0                   1                   2                   3 3
  1133.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1134.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1135.      |      sequence number (2)      | fragment (1)  |no of frags (1)|
  1136.      +-------------------------------+-------------------------------+
  1137.  
  1138.            Followed by up to 50 routing entries (each 8 octets)
  1139.  
  1140.      0                   1                   2                   3 3
  1141.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1142.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1143.      |                       network number (4)                      |
  1144.      +---------------------------------------------------------------+
  1145.      |       number of hops (2)      |      number of ticks (2)      |
  1146.      +---------------------------------------------------------------+
  1147.                                      .
  1148.                                      .
  1149.  
  1150.      The format of a Netware RIP datagram in octets, with each tick mark
  1151.      representing one bit.    All fields are in network order.
  1152.  
  1153.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  1154.      number  of  fragments  (1)  are  not  present  in  the original RIP
  1155.      specification.   They are  only  present  if  operation  takes  the
  1156.      values 7 or 8.
  1157.  
  1158.  
  1159.         Figure 3.   Netware Routing Information Protocol packet format
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174. Meyer                                                          [Page 21]
  1175.  
  1176. Internet Draft                 Demand RIP                       Mar 1995
  1177.  
  1178.  
  1179.        TRIGGERED RESPONSE (7)
  1180.  
  1181.                  A message containing all of the sender's routing data-
  1182.                  base, excluding those entries learned from the inter-
  1183.                  face to which the routing information is being sent.
  1184.  
  1185.                  This message is sent in response to a triggered
  1186.                  request, or as a result of a change in the routing
  1187.                  database.  A triggered response MUST be sent at power
  1188.                  up.
  1189.  
  1190.                  A triggered response message MUST be sent in response
  1191.                  to a triggered request message even if there are no
  1192.                  routes to propagate.  This would be the case for a host
  1193.                  which had a WAN interface only, but which wished to run
  1194.                  the triggered update protocol.
  1195.  
  1196.        TRIGGERED ACKNOWLEDGEMENT (8)
  1197.  
  1198.                  A message sent in response to every triggered response
  1199.                  packet received.
  1200.  
  1201.                  Only the first 6 octets of the packet format shown in
  1202.                  figure 3 are sent.
  1203.  
  1204.    SEQUENCE NUMBER
  1205.  
  1206.              This is a new field inserted if operation takes the values
  1207.              7 or 8.
  1208.  
  1209.              The sequence number MUST be incremented every time updated
  1210.              information is sent out on a WAN.  The sequence number
  1211.              wraps round at 65535.
  1212.  
  1213.              When a triggered acknowledgement is sent the sequence
  1214.              number is set to the same value as the triggered response
  1215.              packet being acknowledged.
  1216.  
  1217.              The sequence number MUST be identical over fragments.  If a
  1218.              fragment is retransmitted the sequence number MUST not
  1219.              change.
  1220.  
  1221.    FRAGMENT NUMBER
  1222.  
  1223.              The fragment number is one for the first fragment of a
  1224.              routing update, and is incremented for each subsequent
  1225.              fragment.  A fragment can contain up to 50 routing entries.
  1226.  
  1227.  
  1228.  
  1229.  
  1230. Meyer                                                          [Page 22]
  1231.  
  1232. Internet Draft                 Demand RIP                       Mar 1995
  1233.  
  1234.  
  1235.              When a triggered acknowledgement is sent the fragment
  1236.              number is set to the same value as the triggered response
  1237.              packet being acknowledged.
  1238.  
  1239.    NUMBER OF FRAGMENTS
  1240.  
  1241.              In a triggered response packet this indicates the number of
  1242.              packets required to complete the routing update.
  1243.  
  1244.              This field has no relevance for triggered acknowledgement
  1245.              packets so should be set to zero.
  1246.  
  1247.    For triggered response packets the rest of the datagram contains a
  1248.    list of networks, with information about each.  Each entry in this
  1249.    list contains a destination network, and the number of hops and
  1250.    number of ticks for each.
  1251.  
  1252.    The maximum datagram size is 406 octets, excluding the IPX header (a
  1253.    further 30 octets).
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286. Meyer                                                          [Page 23]
  1287.  
  1288. Internet Draft                 Demand RIP                       Mar 1995
  1289.  
  1290.  
  1291. 6. Netware Service Advertising Protocol
  1292.  
  1293.    This section should be read in conjunction with references [3], since
  1294.    it only describes differences from the specification.
  1295.  
  1296.    Netware [3] also supports a mechanism that allows servers on an
  1297.    internetwork to advertise their services by name and type using the
  1298.    Service Advertising Protocol (SAP) which runs over the Internetwork
  1299.    Packet Exchange (IPX) protocol using socket number 452h.
  1300.  
  1301.    SAP operates on similar principals to running RIP.  Routers act as
  1302.    SAP agents, collecting service information from different networks
  1303.    and relay it to interested parties.
  1304.  
  1305.    To support the triggered update mechanism outlined in this proposal
  1306.    the packet format for Netware SAP is modified as shown in Figure 4.
  1307.  
  1308.    Every Service Advertising Protocol datagram contains the following:
  1309.  
  1310.    SAP OPERATION
  1311.  
  1312.              Operations supported in standard Netware SAP are: general
  1313.              service query (1), general service response (2), nearest
  1314.              service query (3) and nearest service response (4).
  1315.  
  1316.              The fields sequence number, fragment number and number of
  1317.              fragments MUST NOT be included in packets with these opera-
  1318.              tion values.
  1319.  
  1320.              The following new operations are required:
  1321.  
  1322.        TRIGGERED GENERAL SERVICE QUERY (6)
  1323.  
  1324.                  A request for the responding system to send the identi-
  1325.                  ties of all servers of all types.
  1326.  
  1327.                  Only the first 2 octets of the packet format shown in
  1328.                  figure 4 are sent, since all service types are implied
  1329.                  by this request type.  Any additional octets received
  1330.                  should be ignored.
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342. Meyer                                                          [Page 24]
  1343.  
  1344. Internet Draft                 Demand RIP                       Mar 1995
  1345.  
  1346.  
  1347.  
  1348.      0                   1         1
  1349.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1350.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1351.      |       operation (2)           |
  1352.      +---------------+---------------+
  1353.  
  1354.         The following new fields are inserted for some operations
  1355.  
  1356.      0                   1                   2                   3 3
  1357.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1358.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1359.      |      sequence number (2)      | fragment (1)  |no of frags (1)|
  1360.      +-------------------------------+-------------------------------+
  1361.  
  1362.            Followed by up to 8 service entries (each 64 octets)
  1363.  
  1364.      0                   1                   2                   3 3
  1365.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1366.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1367.      |        Service Type (2)       |                               |
  1368.      +-------------------------------+                               |
  1369.      |                       Service Name (48)                       |
  1370.      |                            .                                  |
  1371.                                   .
  1372.                                   .  +-------------------------------+
  1373.      |                            .  | Network Address (4)           |
  1374.      +-------------------------------+-------------------------------+
  1375.      |  Network Address (cont)       |                               |
  1376.      +-------------------------------+                               |
  1377.      |                        Node Address (6)                       |
  1378.      +-------------------------------+-------------------------------+
  1379.      |      Socket Address (2)       |       Hops to Server (2)      |
  1380.      +-------------------------------+-------------------------------+
  1381.                                      .
  1382.                                      .
  1383.  
  1384.      The format of a Netware SAP datagram in octets, with each tick mark
  1385.      representing one bit.  All fields are in network order.
  1386.  
  1387.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  1388.      number  of  fragments  (1)  are  not  present  in  the original SAP
  1389.      specification.  They are only present if operation takes the values
  1390.      7 or 8.
  1391.  
  1392.  
  1393.         Figure 4.   Netware Service Advertising Protocol packet format
  1394.  
  1395.  
  1396.  
  1397.  
  1398. Meyer                                                          [Page 25]
  1399.  
  1400. Internet Draft                 Demand RIP                       Mar 1995
  1401.  
  1402.  
  1403.        TRIGGERED GENERAL SERVICE RESPONSE (7)
  1404.  
  1405.                  A message containing all of the sender's services
  1406.                  table, excluding those entries learned from the inter-
  1407.                  face to which the service advertising information is
  1408.                  being sent out.
  1409.  
  1410.                  This message is sent in response to a triggered general
  1411.                  service query, or as a result of a change in the ser-
  1412.                  vice advertising database.  A triggered general service
  1413.                  response MUST be sent at power up.
  1414.  
  1415.                  A triggered general service response message MUST be
  1416.                  sent in response to a triggered general request message
  1417.                  even if there are no services to advertise.  This would
  1418.                  be the case for a router with a LAN network which had
  1419.                  work stations but no servers on it.
  1420.  
  1421.        TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)
  1422.  
  1423.                  A message sent in response to every triggered general
  1424.                  service response packet received.
  1425.  
  1426.                  Only the first 6 octets of the packet format shown in
  1427.                  figure 4 are sent.
  1428.  
  1429.    SEQUENCE NUMBER
  1430.  
  1431.              This is a new field inserted if operation takes the values
  1432.              7 or 8.
  1433.  
  1434.              The sequence number MUST be incremented every time updated
  1435.              information is sent out on a WAN.  The sequence number
  1436.              wraps round at 65535.
  1437.  
  1438.              When a triggered general service acknowledgement is sent
  1439.              the sequence number is set to the same value as the trig-
  1440.              gered general service response packet being acknowledged.
  1441.  
  1442.              The sequence number MUST be identical over fragments.  If a
  1443.              fragment is retransmitted the sequence number MUST not
  1444.              change.
  1445.  
  1446.    FRAGMENT NUMBER
  1447.  
  1448.              The fragment number is one for the first fragment of a
  1449.              triggered general service response update, and is incre-
  1450.              mented for each subsequent fragment.  A fragment can
  1451.  
  1452.  
  1453.  
  1454. Meyer                                                          [Page 26]
  1455.  
  1456. Internet Draft                 Demand RIP                       Mar 1995
  1457.  
  1458.  
  1459.              contain up to 8 service entries.
  1460.  
  1461.              When a triggered general service acknowledgement is sent,
  1462.              the fragment number is set to the same value as the trig-
  1463.              gered general service response packet being acknowledged.
  1464.  
  1465.    NUMBER OF FRAGMENTS
  1466.  
  1467.              In a triggered response packet this indicates the number of
  1468.              packets required to complete the service update.
  1469.  
  1470.              This field has no relevance for triggered acknowledgement
  1471.              packets so should be set to zero.
  1472.  
  1473.    For triggered general service response packets the rest of the
  1474.    datagram contains a list of services, with information about each.
  1475.    Each entry in this list contains the service type, service name, full
  1476.    address (network, node and socket), and the number of hops to the
  1477.    server.
  1478.  
  1479.    The maximum datagram size is 534 octets, excluding the IPX header (a
  1480.    further 30 octets).
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510. Meyer                                                          [Page 27]
  1511.  
  1512. Internet Draft                 Demand RIP                       Mar 1995
  1513.  
  1514.  
  1515. 7. Timers
  1516.  
  1517.    A number of timers are supported to handle the triggered update
  1518.    mechanism:
  1519.  
  1520.    o  Database timers.
  1521.  
  1522.    o  Retransmission timer.
  1523.  
  1524.    o  Reassembly timer.
  1525.  
  1526.    In this section appropriate timer values for IP RIP are suggested.
  1527.  
  1528.    For other routing protocols, only the database timer should need to
  1529.    take different values.  The database timer values are chosen to match
  1530.    equivalent timer operation for using the protocol on a LAN.  The
  1531.    behaviour of a routing entry when a timer is running becomes indis-
  1532.    tinguishable from a routing entry learned from a broadcast update.
  1533.  
  1534.    Implementations MAY make timer values configurable - and hence dif-
  1535.    ferent from the values suggested here - but interoperability requires
  1536.    that all timers on a sub-network should be the same in all routers.
  1537.  
  1538. 7.1 Database Timers
  1539.  
  1540.    Routes learned by a triggered response command (7) are normally con-
  1541.    sidered to be permanent - that is they do NOT time out unless
  1542.    activated by one of the following events:
  1543.  
  1544.    o  If the circuit manager indicates that a next hop router cannot be
  1545.       contacted, all routes learned from that next hop router should
  1546.       start timing out as if they had (just) been learned from a conven-
  1547.       tional response command (2).
  1548.  
  1549.       Namely each route exists while the database entry timer is running
  1550.       and is advertised on other interfaces as if still present.  The
  1551.       route is then advertised as unreachable while a further hold down
  1552.       timer is allowed to expire, at which point the entry is deleted.
  1553.  
  1554.       If the circuit manager indicates that the next hop router can be
  1555.       contacted while the database entry timer is running, the routes
  1556.       are reinstated as permanent entries.
  1557.  
  1558.       If the database entry timer has expired and the circuit manager
  1559.       indicates that the next hop router is reachable, the routing
  1560.       application MUST issue a triggered request.  The routes will be
  1561.       reinstated on the basis of any triggered response packet(s)
  1562.       received.
  1563.  
  1564.  
  1565.  
  1566. Meyer                                                          [Page 28]
  1567.  
  1568. Internet Draft                 Demand RIP                       Mar 1995
  1569.  
  1570.  
  1571.    o  If a triggered response packet is received in which a route is
  1572.       marked unreachable, the hold down timer MUST be started and the
  1573.       entry is advertised as unreachable on other interfaces.  On expiry
  1574.       of the hold down timer the entry is deleted.
  1575.  
  1576.       If a triggered response packet is received in which an existing
  1577.       route is ABSENT, the hold down timer MUST also be started and the
  1578.       entry is advertised as unreachable on other interfaces.  On expiry
  1579.       of the hold down timer the entry is deleted.
  1580.  
  1581.    For IP RIP the hold down timer should always run for 120 seconds, to
  1582.    be consistent with RIP usage on broadcast networks.  The database
  1583.    entry timer should by default run for 180 seconds.  The network can
  1584.    be made more responsive by reducing the database entry timer value.
  1585.    However making this timer too short can lead to network instabili-
  1586.    ties.  The duration of the database entry timer allows a period of
  1587.    grace in which contention for network resources can be resolved by
  1588.    the circuit manager.
  1589.  
  1590. 7.2 Retransmission Timer
  1591.  
  1592.    The routing task runs a retransmission timer:
  1593.  
  1594.    o  When a triggered request is sent it will be retransmitted periodi-
  1595.       cally while a triggered response packet is not received.
  1596.  
  1597.    o  When a triggered response is sent a note of the sequence number
  1598.       and fragment number(s) of the routing update is kept.
  1599.  
  1600.       Fragments will be retransmitted at periodic intervals while a
  1601.       triggered acknowledgement packet is not received for the appropri-
  1602.       ate fragment.
  1603.  
  1604.    With call set up time on the WAN being of the order of a second, a
  1605.    value of 5 seconds for the retransmission timer is appropriate.
  1606.  
  1607.    If no response is received after 10 retransmissions, routes via the
  1608.    next hop router are marked as unreachable, the hold down timer MUST
  1609.    be started and the entry is advertised as unreachable on other inter-
  1610.    faces.  On expiry of the hold down timer the entry is deleted.
  1611.  
  1612.    The next hop router is then polled using a triggered request packet
  1613.    at 60 second intervals.  If a response is received the routers should
  1614.    exchange routing information using triggered response packets.
  1615.  
  1616.    It may not be desirable to poll indefinitely, since a lack of
  1617.    response (when a circuit is up) is most likely caused by incorrect
  1618.    configuration of the next hop router.  An administrator definable
  1619.  
  1620.  
  1621.  
  1622. Meyer                                                          [Page 29]
  1623.  
  1624. Internet Draft                 Demand RIP                       Mar 1995
  1625.  
  1626.  
  1627.    number of polls (5 or greater) should be provided.
  1628.  
  1629.    If the circuit manager indicates that the next hop router is unreach-
  1630.    able, the retransmission is suppressed until the circuit manager
  1631.    indicates that the next hop router is reachable once more.  Counting
  1632.    of the number of retransmissions continues from where it left off
  1633.    prior to the circuit down indication.
  1634.  
  1635. 7.3 Reassembly Timer
  1636.  
  1637.    When a router receives a triggered response update it MUST ack-
  1638.    nowledge each fragment.  If the routing update is fragmented over
  1639.    more than one packet, the receiving router MUST store the fragments
  1640.    until ALL fragments are received.
  1641.  
  1642.    On receiving the first fragment a timer should be started.  If all
  1643.    fragments of the routing update are not received within that period
  1644.    they are discarded - and a triggered request is sent back to the ori-
  1645.    ginator (with retransmissions if necessary).  The originator MUST
  1646.    then resend ALL triggered response fragments
  1647.  
  1648.    The reassembly timer should be set to four times the value of the
  1649.    retransmission timer.  With a suggested retransmission timer value of
  1650.    5 seconds, the suggested reassembly timer value SHOULD be 20 seconds.
  1651.  
  1652.    Implementations MAY allow the reassembly timer and retransmission
  1653.    timer to be configurable (in the 1:4 ratio), but interoperability
  1654.    will be compromised on WANs where all participating routers DO NOT
  1655.    support the same values for these timers.
  1656.  
  1657.    Fragments MUST also be discarded if a new fragment with a different
  1658.    sequence number is received.  A triggered request MUST not be sent in
  1659.    this instance.
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678. Meyer                                                          [Page 30]
  1679.  
  1680. Internet Draft                 Demand RIP                       Mar 1995
  1681.  
  1682.  
  1683. 8. Implementation Considerations
  1684.  
  1685.    In the implementation described in this memo, it is assumed that
  1686.    there is a close binding between the circuit manager and the routing
  1687.    applications - that they are in some way the same 'program'.  This is
  1688.    not necessarily true of all products which are routers.
  1689.  
  1690.    In particular there are UNIX host implementations in which the rout-
  1691.    ing application is distinct from the kernel, where the circuit
  1692.    manager is likely to be installed.  In such systems it is possible to
  1693.    stop (or crash) the routing applications independently of what is
  1694.    happening in the kernel.
  1695.  
  1696.    Other implementations might have the circuit manager on a separate
  1697.    card which again may give the circuit manager a life of its own.
  1698.  
  1699.    In implementations where the applications and circuit manager have
  1700.    independent lives, a keep-alive mechanism MUST be provided between
  1701.    the applications and the circuit manager, so that if the application
  1702.    or network layer dies and is subsequently re-started they can re-
  1703.    synchronise their state tables.
  1704.  
  1705.    Ideally when an application dies, the circuit manager should close
  1706.    all existing VCs appropriate to the application and make no further
  1707.    outgoing calls and reject incoming calls until the application is
  1708.    running again.
  1709.  
  1710.    If the circuit manager is using some form of encapsulation, several
  1711.    applications may be sharing the same VC.  If this is the case the
  1712.    circuit manager may wish to filter out datagrams for the appropriate
  1713.    network layer if only one of the applications is affected.  But this
  1714.    is not an ideal solution.
  1715.  
  1716.    Conversely if the application believes the circuit manager has died,
  1717.    it should mark all routes via the circuit manager as unreachable and
  1718.    advertise them on other interfaces for the duration of the hold down
  1719.    timer before deleting them.
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734. Meyer                                                          [Page 31]
  1735.  
  1736. Internet Draft                 Demand RIP                       Mar 1995
  1737.  
  1738.  
  1739. 9. Security Considerations
  1740.  
  1741.    Security is provided my a number of aspects:
  1742.  
  1743.    o  The circuit manager is required to be provided with a list of phy-
  1744.       sical addresses to enable it to establish a call to the next hop
  1745.       router on an X.25 SVC or ISDN B-channel.
  1746.  
  1747.       The circuit manager SHOULD only allow incoming calls to be
  1748.       accepted from the same well defined list of routers.
  1749.  
  1750.       Elsewhere in the system there will be a set of logical address and
  1751.       physical address tuples to enable the network protocols to run
  1752.       over the correct circuit.  This may be a lookup table, or in some
  1753.       instances there may be an algorithmic conversion between the two
  1754.       addresses.
  1755.  
  1756.    o  The routing (or service advertising) task MUST be provided with a
  1757.       list of logical addresses to which triggered updates are to be
  1758.       sent on the WAN.  The list MAY be a subset of the list of next hop
  1759.       routers maintained by the circuit manager.
  1760.  
  1761.       There MAY also be a separate list of next hop routers to which
  1762.       traditional broadcasts of routing (or service advertising) updates
  1763.       should be sent.  Next hop routers omitted from either list are
  1764.       assumed to be not participating in routing (or service advertis-
  1765.       ing) updates.
  1766.  
  1767.       The list (or lists) doubles as a list of routers from which rout-
  1768.       ing updates are allowed to be received from the WAN.  Any routing
  1769.       information received from a router not in the appropriate list
  1770.       MUST be discarded.
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790. Meyer                                                          [Page 32]
  1791.  
  1792. Internet Draft                 Demand RIP                       Mar 1995
  1793.  
  1794.  
  1795. References
  1796.  
  1797.  
  1798.    [1]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
  1799.         University, June 1988.
  1800.  
  1801.    [2]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
  1802.         RFC 1723, Xylogics, November 1994.
  1803.  
  1804.    [3]  Novell Incorporated., "IPX Router Specification", Version 1.10,
  1805.         October 1992.
  1806.  
  1807.    [4]  Xerox Corporation., "Internet Transport Protocols", Xerox System
  1808.         Integration Standard XSIS 028112, December 1981.
  1809.  
  1810.    [5]  Malis. A., Robinson. D., and Ullmann. R., "Multiprotocol Inter-
  1811.         connect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN Com-
  1812.         munications, Computervision Systems Integration and Process
  1813.         Software Corporation, August 1992.
  1814.  
  1815. Author's  Address:
  1816.  
  1817.    Gerry Meyer
  1818.    Spider Systems
  1819.    Stanwell Street
  1820.    Edinburgh EH6 5NG
  1821.    Scotland, UK
  1822.  
  1823.    Phone: (UK) 31 554 9424
  1824.    Fax:   (UK) 31 554 0649
  1825.    Email: gerry@spider.co.uk
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846. Meyer                                                          [Page 33]
  1847.  
  1848.