rfc1476.txt

RFC 的详细文档！

RFC 1476                          RAP                          June 1993


   -------------------------------------------------------------------

           [incoming routes]
                   |
                   v
           [proximity filtering/aggregation]       [static routes]
                   |                                  |
                   v                                  v
           [route database]  --->  [selected active routes]
                   ^                       |
                   |                       v
           [RIP, etc. routes]      [output filtering]
                                           |
                                           v
                                   [routes advertised]

   -------------------------------------------------------------------

4.1  Receiver filtering

   The first step is to filter out offered routes that are too "far
   away" or too specific.  The filter consists of a maximum distance at
   which a route is considered usable for each possible (contiguous)
   mask.

   Routers that need universal connectivity must either pass through the
   filter all routes regardless of distance (short of "infinity"), and
   use aggregation to reduce them, or have a default route to a router
   that does this.

   The filter may be adjusted dynamically to fit limited resources, but
   if the filter is opened, i.e., made less restrictive, there may be
   routes that have already been offered and discarded that will never
   become available.

4.2  Update of metrics and options

   The process then updates any metrics present on the route to reflect
   the path to the RAP peer.  MTU and bandwidth are minimized, delay and
   cost are added in.  Distance is incremented.  Any unknown options
   cause class-dependent processing:  discarding the option (class 2) or
   route (3), or marking the route as non-propagatable (1).

   Policy options that are known may cause the route to be discarded at
   this stage.






Ullmann                                                        [Page 16]

RFC 1476                          RAP                          June 1993


4.3  Aggregation

   The next step is to aggregate routes that are subsetted by other
   routes through the same peer.  This should not be done automatically
   in every possible case.  The more information that is propagated, the
   more effective the use of forward route identifiers is likely to be,
   particularily in the case of aggregating into a default route.

   In general, a route can be included in an aggregate, and not
   propagated further, if it is through the same peer (next hop) and has
   a smaller distance metric than the containing route.  (Thus datagrams
   will always travel "downhill" as they take more specific routes.)

   The usual case of aggregation is that routes derived from interface
   configurations on the routers from which they originated are subsumed
   into routes offered by routers explicitly configured to route for an
   entire network, area, or AD.  If the larger area becomes partitioned,
   unaggregatable routes will appear (as routes outside the area become
   the shortest distance routes) and traffic will flow around the
   partition.

   Attributes of routes, particularily policy options, may prevent
   aggregation and may result in routes simply being discarded.

   Some information about aggregation also needs to be represented in
   the forwarding database, if the route is made active:  the router
   will need to make a decision as to which forward route identifier to
   use for each datagram arriving on the active route.

4.4  Active route selection

   The router selects those routes to be entered into the IP forwarding
   database and actively used to forward datagrams from the set of
   routes after aggregation, combined with routes derived from other
   protocols such as RIP.  This selection may be made on any combination
   of attributes and options desired by local policy.

4.5  Transmitter filtering

   Finally, the RAP process must decide which routes to offer to its
   peers.  These must be a subset of the active routes, and may in turn
   be a selected subset for each peer.  Arbitrary local policies may be
   used in deciding whether or not to offer any particular route to a
   given peer.

   However, the transmitter must ensure that any datagram filters are
   represented in the offered route, so that the peer (and its peers)
   will not route into a black hole.



Ullmann                                                        [Page 17]

RFC 1476                          RAP                          June 1993


4.6  Last resort loop prevention

   RAP is designed to support many different kinds of routing selection
   algorithms, and allow them to interact to varying extents.  Routes
   can be shared among administrations, and between systems managed with
   more or less sophistication.

   This leaves one absolute requirement:  routing loops must be self-
   healing, regardless of the algorithm used on each host.  There are
   two caveats:

     1.  A loop will not fix itself in the presence of an error that
         continually recurs (thus re-generating the loop)

     2.  The last resort algorithm does not provide rapid breaking of
         loops, only eventual breaking of them even in the absence of
         any intervention by (human) intelligence.

   The algorithm relies on the distance in the RAP route header.  This
   count must be updated (i.e., incremented by one) at each router
   forwarding the route.

   Routers must also impose some limit on the number of hops permitted
   in incoming routes, discarding any routes that exceed the limit.
   This limit is "infinity" in the classic algorithm.  In RIP, infinity
   is 15, much too low for general inter-domain routing.

   In RAP, infinity is defined as 2z + i, where z is the number of zero
   bits in the mask (as described previously) and i is a small number
   which MUST be configurable.

   Note that RAP depends on the last resort algorithm, "counting to
   infinity," much less than predecessors such as RIP.  Routes in the
   RAP domain will usually be purged from the net as the purge route
   command is flooded without the delays typical of periodic broadcast
   algorithms.  Only in some cases will loops form, and they will be
   counted out as fast as the routing processes can exchange the
   information.

5.  Conclusion

   Unlike prior routing protocols, RAP is designed to solve the entire
   problem, from hands-off autoconfiguration of LAN networks, to
   implementing the most complex policies of international carriers.  It
   provides a scaleable solution to carry the Internet forward to a
   future in which essentially all users of data transmission use IP as
   the fabric of their networks.




Ullmann                                                        [Page 18]

RFC 1476                          RAP                          June 1993


6.  Appendix:  Real Number Representation

   Real numbers are represented by a one byte exponent, e, in excess-128
   notation, and a fraction, f, in excess-8388608 notation, with the
   radix point at the right.  (I.e., the "fraction" is actually an
   integer.)

   e is thus in the range 0 to 255, representing exponents (powers of 2)
   in the range 2^-128 to 2^127.

   f is in the range 0 to 16777215, representing numbers from -8388608
   to 8388607

   The value is (f-8338608) x 2^(e-128)

   The real number is not necessarily normalized, but a normalized
   representation will, of course, provide more accuracy for numbers not
   exactly representable.

   Example code, in C:

   #include <math.h>

   typedef struct {
           unsigned e : 8;
           unsigned f : 24;
           } real;

   double a;          /* input value */
   real r;
   double b;          /* output value */
   double d;
   int e32;

   /* convert to real: */

   d = frexp(a, &e32);
   r.e = e32+105;
   r.f = (int)(d*8388608.0) + 8388608;

   /* convert back: */

   b = ldexp((double)r.f - 8388608.0, (int)r.e - 128);








Ullmann                                                        [Page 19]

RFC 1476                          RAP                          June 1993


7.  References

   [ISO3166]   International Organization for Standardization.  Codes
               for the Representation of Names of Countries.  ISO
               3166, ISO, 1988.

   [ISO4217]   International Organization for Standardization.  Codes
               for the representation of currencies and funds.  ISO
               4217, ISO, 1981.

   [RFC791]    Postel, J., "Internet Protocol - DARPA Internet Program
               Protocol Specification", STD 5, RFC 791, DARPA,
               September 1981.

   [RFC1058]   Hedrick, C., "Routing Information Protocol", STD 34,
               RFC 1058, Rutgers University, June 1988.

   [RFC1247]   Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
               July 1991.

   [RFC1287]   Clark, D., Chapin, L., Cerf, V., Braden, R., and
               R. Hobby, "Towards the Future Internet Architecture",
               RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.

   [RFC1338]   Fuller, V., Li, T., Yu, J., and K. Varadhan,
               "Supernetting: an Address Assignment and Aggregation
               Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet,
               June 1992.

   [RFC1475]   Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
               Process Software Corporation, June 1993.

8.  Security Considerations

   Security issues are discussed in sections 3.2.9 and 3.2.12.

9.  Author's Address

   Robert Ullmann
   Process Software Corporation
   959 Concord Street
   Framingham, MA 01701
   USA

   Phone: [phone] x226
   Email: [e-mail]





Ullmann                                                        [Page 20]