rfc2091.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                           G. Meyer
Request for Comments: 2091                                         Shiva
Category: Standards Track                                      S. Sherry
                                                                  Xyplex
                                                            January 1997


         Triggered Extensions to RIP to Support Demand Circuits

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines a modification which can be applied to
   Bellman-Ford (distance vector) algorithm information broadcasting
   protocols - for example IP RIP, Netware RIP or Netware SAP - which
   makes it feasible to run them on connection oriented Public Data
   Networks.

   This proposal has a number of efficiency advantages over the Demand
   RIP proposal (RFC 1582).

Acknowledgements

   The authors wish to thank Richard Edmonstone of Shiva, Joahanna
   Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of Conware
   for many comments and suggestions which improved this effort.

Conventions

   The following language conventions are used in the items of
   specification in this document:

   o  MUST -- the item is an absolute requirement of the specification.
      MUST is only used where it is actually required for
      interoperation, not to try to impose a particular method on
      implementors where not required for interoperability.

   o  SHOULD -- the item should be followed for all but exceptional
      circumstances.





Meyer & Sherry              Standards Track                     [Page 1]

RFC 2091                      Trigger RIP                   January 1997


   o  MAY or optional -- the item is truly optional and may be followed
      or ignored according to the needs of the implementor.

      The words "should" and "may" are also used, in lower case, in
      their more ordinary senses.

Table of Contents

   1. Introduction ...........................................  2
   2. Overview ...............................................  3
   3. The Routing Database ...................................  5
       3.1. Presumption of Reachability ......................  6
       3.2. Alternative Routes ...............................  6
       3.3. Split Horizon with Poisoned Reverse ..............  7
       3.4. Managing Updates .................................  7
       3.5. Retransmissions ..................................  7
   4. New Packet Types .......................................  8
       4.1. Update Request (9) ...............................  9
       4.2. Update Response (10) .............................  9
       4.3. Update Acknowledge (11) .......................... 10
   5. Packet Formats ......................................... 10
       5.1. Update Header .................................... 10
       5.2. IP Routing Information Protocol Version 1 ........ 11
       5.3. IP Routing Information Protocol Version 2 ........ 11
       5.4. Netware Routing Information Protocol ............. 12
       5.5. Netware Service Advertising Protocol ............. 12
   6. Timers ................................................. 17
       6.1. Database Timer ................................... 17
       6.2. Hold Down Timer .................................. 17
       6.3. Retransmission Timer ............................. 18
       6.4. Over-subscription Timer .......................... 18
   7. Security Considerations ................................ 19
   Appendix A - Implementation Suggestion .................... 20
   References ................................................ 21
   Authors' Addresses ........................................ 22

1. Introduction

   Routers are used on connection oriented networks, such as X.25 packet
   switched networks and ISDN networks, to allow potential connectivity
   to a large number of remote destinations.  Circuits on the Wide Area
   Network (WAN) are established on demand and are relinquished when the
   traffic subsides.  Depending on the application, the connection
   between any two sites for user data might actually be short and
   relatively infrequent.






Meyer & Sherry              Standards Track                     [Page 2]

RFC 2091                      Trigger RIP                   January 1997


   Periodic broadcasting by Bellman-Ford (distance vector) algorithm
   information broadcasting protocols IP RIP [1], IP RIP V2 [2] or
   Netware RIP and SAP [3] generally prevents WAN circuits from being
   closed.  Even on fixed point-to-point links the overhead of periodic
   transmission of RIP - and even more so SAP broadcasts - can seriously
   interrupt normal data transfer simply through the quantity of
   information which hits the line every 30 or 60 seconds.

   To overcome these limitations, this specification modifies the
   distance vector protocols so as to send information on the WAN only
   when there has been an update to the routing database OR a change in
   the reachability of a next hop router is indicated by the task which
   manages connections on the WAN.

   Because datagrams are not guaranteed to get through on all WAN media,
   an acknowledgement and retransmission system is required to provide
   reliability.

   The protocols run unmodified on Local Area Networks (LANs) and so
   interoperate transparently with implementations adhering to the
   original specifications.

   This proposal differs from Demand RIP [4] conceptually as follows:

   o  If a router has exchanged all routing information with its partner
      and some routing information subsequently changes only the changed
      information is sent to the partner.

   o  The receiver of routes is able to apply all changes immediately
      upon receiving information from a partner.

   These differences lead to further reduced routing traffic and also
   require less memory than Demand RIP [4].  Demand RIP also has an
   upper limit of 255 fragments in an update which is lifted in
   Triggered RIP (which does not use fragmentation).

2. Overview

   Multiprotocol routers are used on connection oriented Wide Area
   Networks (WANs), such as X.25 packet switched networks and ISDN
   networks, to interconnect LANs.  By using the multiplexing properties
   of the underlying WAN technology, several LANs can be interconnected
   simultaneously through a single physical interface on the router.








Meyer & Sherry              Standards Track                     [Page 3]

RFC 2091                      Trigger RIP                   January 1997


   A circuit manager provides an interface between the connectionless
   network layers, IP and IPX, and the connection oriented WAN, X.25,
   ISDN etc.  Figure 1 shows a schematic representative stack showing
   the relationship between routing protocols, the network layers, the
   circuit manager and the connection oriented WAN.

             --------------           ---------  ---------
             |    RIP     |           |  RIP  |  |  SAP  |
             --------------           ---------  ---------
                   |                      |          |
             --------------               |          |
             |    UDP     |               |          |
             --------------               |          |
                   |                      |          |
             --------------             ----------------
             |    IP      |             |     IPX      |
             --------------             ----------------
                   |                           |
             -------------------------------------------
             |             Circuit Manager             |
             -------------------------------------------
                              ||||||||||
                              ||||||||||
                      ---------------------------
                      |   Connection Oriented   |
                      |        WAN stack        |
                      ---------------------------

      A WAN circuit manager will  support  a  variety  of  network
      layer protocols,  on its upper interface.  On its lower interface,
      it may support one or more subnetworks.  A subnetwork may support
      a number of Virtual Circuits.

            Figure 1.   Representative Multiprotocol Router stack

   The router has a translation table which relates the network layer
   address of the next hop router to the physical address used to
   establish a Virtual Circuit (VC) to it.

   The circuit manager takes datagrams from the connectionless network
   layer protocols and (if one is not currently available) opens a VC to
   the next hop router.  A VC can carry all traffic between two end-
   point routers for a given network layer protocol (or with appropriate
   encapsulation all network layer protocols).  An idle timer (or some
   other mechanism) is used to close the VC when the datagrams stop
   arriving at the circuit manager.





Meyer & Sherry              Standards Track                     [Page 4]

RFC 2091                      Trigger RIP                   January 1997


   If the circuit manager has data to forward (whether user data OR a
   routing update) and fails to obtain a VC it informs the routing
   application that the destination is unreachable (circuit down).  The
   circuit manager is then expected to perform whatever is necessary to
   recover the link.   Once successful, it informs the routing
   application (circuit up).

   In Triggered RIP, routing updates are only transmitted on the WAN
   when required:

   1  When a specific request for a routing update has been received.

   2  When the routing database is modified by new information from
      another interface.

   3  When the circuit manager indicates that a destination has changed
      from an unreachable (circuit down) to a reachable (circuit up)
      state.

   4  And also when a unit is first powered on to ensure that at least
      one update is sent.  This can be thought of as a transition from
      circuit down to circuit up.  It MAY contain no routes or services,
      and is used to flush routes or services from the peer's database.

   In cases 1,3 and 4 the full contents of the database is sent.  In
   case 2 only the latest changes are sent.

   Because of the inherent unreliability of a datagram based system,
   both routing requests and routing responses require acknowledgement,
   and retransmission in the event of NOT receiving an acknowledgement.

3. The Routing Database

   Entries in the routing database can either be permanent or temporary.
   Entries learned from broadcasts on LANs are temporary. They will
   expire if not periodically refreshed by further broadcasts.

   Entries learned from a triggered response on the WAN are 'permanent'.
   They MUST not time out in the normal course of events.  Certain
   events can cause these routes to time out.











Meyer & Sherry              Standards Track                     [Page 5]

RFC 2091                      Trigger RIP                   January 1997


3.1 Presumption of Reachability

   If a routing update is received from a next hop router on the WAN,
   entries in the update are thereafter always considered to be
   reachable, unless proven otherwise:

   o  If in the normal course of routing datagrams, the circuit manager
      fails to establish a connection to the next hop router, it
      notifies the routing application that the next hop router is not
      reachable through an internal circuit down message.

      The database entries are first marked as temporary and aged
      normally; Some implementations may choose to omit this initial
      aging step.  The routing application then marks the appropriate
      database entries as unreachable for a hold down period (the normal
      120 second RIP hold down timer).

   o  If the circuit manager is subsequently able to establish a
      connection to the next hop router, it will notify the routing
      application that the next hop router is reachable through an
      internal circuit up message.

      The routing application will then exchange messages with the next
      hop router so as to re-prime their respective routing databases
      with up-to-date information.

   The next hop router may also be marked as unreachable if an excessive
   number of retransmissions of an update go unacknowledged (see section
   6.3).

   Handling of circuit up and circuit down messages requires that the
   circuit manager takes responsibility for establishing (or re-
   establishing) the connection in the event of a next hop router
   becoming unreachable.  A description of the processes the circuit
   manager adopts to perform this task is outside the scope of this
   document.

3.2 Alternative Routes

   A requirement of using Triggered RIP for propagating routing
   information is that NO routing information ever gets LOST or
   DISCARDED.  This means that all alternative routes SHOULD be
   retained.

   It MAY be possible to operate with a sub-set of all alternative
   routes, but this adds complexity to the protocol - which is NOT
   covered in this document.




Meyer & Sherry              Standards Track                     [Page 6]

RFC 2091                      Trigger RIP                   January 1997


3.3 Split Horizon with Poisoned Reverse

   The rules for Split Horizon with Poisoned Reverse MUST be used to
   determine whether and/or how a route is advertised on an interface
   running this protocol.

   Split Horizon consists of omitting routes learned from a peer when
   sending updates back to that peer.  With Poisoned Reverse instead of
   omitting those routes, they are advertised as unreachable (setting
   the metric to infinity).

   A route is only poisoned if it is the best route (rather than an
   inferior alternative route) in the database.

   Poison Reverse is necessary because a router may be advertising a
   route to a network to its partner and then later learn a better route
   for the same network from the partner.  Without Poison Reverse the
   partner will not know to discard the inferior route learned from the
   first router.

3.4 Managing Routing Updates

   The routing database SHOULD be considered to be a sequence of
   elements ordered by the time it was last updated.  If there is a
   change in the best route (i.e. a new route is added or a route's
   metric has changed), the route is reordered and given a new highest
   sequence number.

   Sending updates to a peer consists of running through the database
   from the oldest entry to the newest entry.  Once an entry has been
   sent and acknowledged it is generally never resent.  As new routing
   information arrives, only the new information is sent.

3.5 Retransmissions

   Handling retransmission of updates is simplest if updates are
   restricted to never having more than one un-acknowledged update
   outstanding - "one packet in flight".  A copy of the update packet
   can be kept and retransmitted until acknowledged - and then
   subsequent update packets are sent in turn until the full database
   (to date) has been sent and acknowledged.










Meyer & Sherry              Standards Track                     [Page 7]

RFC 2091                      Trigger RIP                   January 1997


   Things become more complicated if several packets are sent in quick
   succession without waiting for an acknowledgements between packets -
   "several packets in flight":

   o  If packets arrive out of order they could corrupt the peer's
      database.  If the underlying datalink layer bundles several VCs,
      it MUST guarantee to NOT reorder datagrams.

   o  If the elements making up a packet requiring retransmission change
      because of an alteration in the database, stale incorrect
      information could be sent (again new information could overtake
      old information).

   To guard against this when 'retransmitting' a packet when the