rfc2453.txt

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

   You should now see why "infinity" is chosen to be as small as
   possible.  If a network becomes completely inaccessible, we want
   counting to infinity to be stopped as soon as possible.  Infinity
   must be large enough that no real route is that big.  But it
   shouldn't be any bigger than required.  Thus the choice of infinity
   is a tradeoff between network size and speed of convergence in case
   counting to infinity happens.  The designers of RIP believed that the
   protocol was unlikely to be practical for networks with a diameter
   larger than 15.

   There are several things that can be done to prevent problems like
   this.  The ones used by RIP are called "split horizon with poisoned
   reverse", and "triggered updates".

3.4.3 Split horizon

   Note that some of the problem above is caused by the fact that A and
   C are engaged in a pattern of mutual deception.  Each claims to be
   able to get to D via the other.  This can be prevented by being a bit
   more careful about where information is sent.  In particular, it is
   never useful to claim reachability for a destination network to the
   neighbor(s) from which the route was learned.  "Split horizon" is a
   scheme for avoiding problems caused by including routes in updates
   sent to the router from which they were learned.  The "simple split
   horizon" scheme omits routes learned from one neighbor in updates
   sent to that neighbor.  "Split horizon with poisoned reverse"
   includes such routes in updates, but sets their metrics to infinity.

   If A thinks it can get to D via C, its messages to C should indicate
   that D is unreachable.  If the route through C is real, then C either
   has a direct connection to D, or a connection through some other
   router.  C's route can't possibly go back to A, since that forms a
   loop.  By telling C that D is unreachable, A simply guards against
   the possibility that C might get confused and believe that there is a
   route through A.  This is obvious for a point to point line.  But
   consider the possibility that A and C are connected by a broadcast
   network such as an Ethernet, and there are other routers on that
   network.  If A has a route through C, it should indicate that D is
   unreachable when talking to any other router on that network.  The
   other routers on the network can get to C themselves.  They would
   never need to get to C via A.  If A's best route is really through C,
   no other router on that network needs to know that A can reach D.
   This is fortunate, because it means that the same update message that



Malkin                      Standards Track                    [Page 15]

RFC 2453                     RIP Version 2                 November 1998


   is used for C can be used for all other routers on the same network.
   Thus, update messages can be sent by broadcast.

   In general, split horizon with poisoned reverse is safer than simple
   split horizon.  If two routers have routes pointing at each other,
   advertising reverse routes with a metric of 16 will break the loop
   immediately.  If the reverse routes are simply not advertised, the
   erroneous routes will have to be eliminated by waiting for a timeout.
   However, poisoned reverse does have a disadvantage: it increases the
   size of the routing messages.  Consider the case of a campus backbone
   connecting a number of different buildings.  In each building, there
   is a router connecting the backbone to a local network.  Consider
   what routing updates those routers should broadcast on the backbone
   network.  All that the rest of the network really needs to know about
   each router is what local networks it is connected to.  Using simple
   split horizon, only those routes would appear in update messages sent
   by the router to the backbone network.  If split horizon with
   poisoned reverse is used, the router must mention all routes that it
   learns from the backbone, with metrics of 16.  If the system is
   large, this can result in a large update message, almost all of whose
   entries indicate unreachable networks.

   In a static sense, advertising reverse routes with a metric of 16
   provides no additional information.  If there are many routers on one
   broadcast network, these extra entries can use significant bandwidth.
   The reason they are there is to improve dynamic behavior.  When
   topology changes, mentioning routes that should not go through the
   router as well as those that should can speed up convergence.
   However, in some situations, network managers may prefer to accept
   somewhat slower convergence in order to minimize routing overhead.
   Thus implementors may at their option implement simple split horizon
   rather than split horizon with poisoned reverse, or they may provide
   a configuration option that allows the network manager to choose
   which behavior to use.  It is also permissible to implement hybrid
   schemes that advertise some reverse routes with a metric of 16 and
   omit others.  An example of such a scheme would be to use a metric of
   16 for reverse routes for a certain period of time after routing
   changes involving them, and thereafter omitting them from updates.

   The router requirements RFC [11] specifies that all implementation of
   RIP must use split horizon and should also use split horizon with
   poisoned reverse, although there may be a knob to disable poisoned
   reverse.








Malkin                      Standards Track                    [Page 16]

RFC 2453                     RIP Version 2                 November 1998


3.4.4  Triggered updates

   Split horizon with poisoned reverse will prevent any routing loops
   that involve only two routers.  However, it is still possible to end
   up with patterns in which three routers are engaged in mutual
   deception.  For example, A may believe it has a route through B, B
   through C, and C through A.  Split horizon cannot stop such a loop.
   This loop will only be resolved when the metric reaches infinity and
   the network involved is then declared unreachable.  Triggered updates
   are an attempt to speed up this convergence.  To get triggered
   updates, we simply add a rule that whenever a router changes the
   metric for a route, it is required to send update messages almost
   immediately, even if it is not yet time for one of the regular update
   message.  (The timing details will differ from protocol to protocol.
   Some distance vector protocols, including RIP, specify a small time
   delay, in order to avoid having triggered updates generate excessive
   network traffic.)  Note how this combines with the rules for
   computing new metrics.  Suppose a router's route to destination N
   goes through router G.  If an update arrives from G itself, the
   receiving router is required to believe the new information, whether
   the new metric is higher or lower than the old one.  If the result is
   a change in metric, then the receiving router will send triggered
   updates to all the hosts and routers directly connected to it.  They
   in turn may each send updates to their neighbors.  The result is a
   cascade of triggered updates.  It is easy to show which routers and
   hosts are involved in the cascade.  Suppose a router G times out a
   route to destination N.  G will send triggered updates to all of its
   neighbors.  However, the only neighbors who will believe the new
   information are those whose routes for N go through G.  The other
   routers and hosts will see this as information about a new route that
   is worse than the one they are already using, and ignore it.  The
   neighbors whose routes go through G will update their metrics and
   send triggered updates to all of their neighbors.  Again, only those
   neighbors whose routes go through them will pay attention.  Thus, the
   triggered updates will propagate backwards along all paths leading to
   router G, updating the metrics to infinity.  This propagation will
   stop as soon as it reaches a portion of the network whose route to
   destination N takes some other path.

   If the system could be made to sit still while the cascade of
   triggered updates happens, it would be possible to prove that
   counting to infinity will never happen.  Bad routes would always be
   removed immediately, and so no routing loops could form.

   Unfortunately, things are not so nice.  While the triggered updates
   are being sent, regular updates may be happening at the same time.
   Routers that haven't received the triggered update yet will still be
   sending out information based on the route that no longer exists.  It



Malkin                      Standards Track                    [Page 17]

RFC 2453                     RIP Version 2                 November 1998


   is possible that after the triggered update has gone through a
   router, it might receive a normal update from one of these routers
   that hasn't yet gotten the word.  This could reestablish an orphaned
   remnant of the faulty route.  If triggered updates happen quickly
   enough, this is very unlikely.  However, counting to infinity is
   still possible.

   The router requirements RFC [11] specifies that all implementation of
   RIP must implement triggered update for deleted routes and may
   implement triggered updates for new routes or change of routes.  RIP
   implementations must also limit the rate which of triggered updates
   may be trandmitted. (see section 3.10.1)

3.5 Protocol Specification

   RIP is intended to allow routers to exchange information for
   computing routes through an IPv4-based network.  Any router that uses
   RIP is assumed to have interfaces to one or more networks, otherwise
   it isn't really a router.  These are referred to as its directly-
   connected networks.  The protocol relies on access to certain
   information about each of these networks, the most important of which
   is its metric.  The RIP metric of a network is an integer between 1
   and 15, inclusive.  It is set in some manner not specified in this
   protocol; however, given the maximum path limit of 15, a value of 1
   is usually used.  Implementations should allow the system
   administrator to set the metric of each network.  In addition to the
   metric, each network will have an IPv4 destination address and subnet
   mask associated with it.  These are to be set by the system
   administrator in a manner not specified in this protocol.

   Any host that uses RIP is assumed to have interfaces to one or more
   networks.  These are referred to as its "directly-connected
   networks".  The protocol relies on access to certain information
   about each of these networks.  The most important is its metric or
   "cost".  The metric of a network is an integer between 1 and 15
   inclusive.  It is set in some manner not specified in this protocol.
   Most existing implementations always use a metric of 1.  New
   implementations should allow the system administrator to set the cost
   of each network.  In addition to the cost, each network will have an
   IPv4 network number and a subnet mask associated with it.  These are
   to be set by the system administrator in a manner not specified in
   this protocol.

   Note that the rules specified in section 3.7 assume that there is a
   single subnet mask applying to each IPv4 network, and that only the
   subnet masks for directly-connected networks are known.  There may be
   systems that use different subnet masks for different subnets within
   a single network.  There may also be instances where it is desirable



Malkin                      Standards Track                    [Page 18]

RFC 2453                     RIP Version 2                 November 1998


   for a system to know the subnets masks of distant networks. Network-
   wide distribution of routing information which contains different
   subnet masks is permitted if all routers in the network are running
   the extensions presented in this document. However, if all routers in
   the network are not running these extensions distribution of routing
   information containing different subnet masks must be limited to
   avoid interoperability problems. See sections 3.7 and 4.3 for the
   rules governing subnet distribution.

   Each router that implements RIP is assumed to have a routing table.
   This table has one entry for every destination that is reachable
   throughout the system operating RIP.  Each entry contains at least
   the following information:

   - The IPv4 address of the destination.

   - A metric, which represents the total cost of getting a datagram
     from the router to that destination.  This metric is the sum of the
     costs associated with the networks that would be traversed to get
     to the destination.

   - The IPv4 address of the next router along the path to the
     destination (i.e., the next hop).  If the destination is on one of
     the directly-connected networks, this item is not needed.

   - A flag to indicate that information about the route has changed
     recently.  This will be referred to as the "route change flag."

   - Various timers associated with the route.  See section 3.6 for more
     details on timers.

   The entries for the directly-connected networks are set up by the
   router using information gathered by means not specified in this
   protocol.  The metric for a directly-connected network is set to the
   cost of that network.  As mentioned, 1 is the usual cost.  In that
   case, the RIP metric reduces to a simple hop-count.  More complex
   metrics may be used when it is desirable to show preference for some
   networks over others (e.g., to indicate of differences in bandwidth
   or reliability).

   To support the extensions detailed in this document, each entry must
   additionally contain a subnet mask. The subnet mask allows the router
   (along with the IPv4 address of the destination) to identify the
   different subnets within a single network as well as the subnets
   masks of distant networks.