rfc1476.txt

中、英文RFC文档大全打包下载完全版 .

   propagates confidential information about the security configuration,
   but only toward the net authorized to use the route if the RAP
   implementation is careful about where it is propagated.

3.2.10  Destination Restriction

   A destination restriction option (type 10, format 4, class 3) serves
   only to provide a non-contiguous mask, the destination already having
   been specified in the command header.  Data is the destination
   network and mask.

3.2.11  Trace

   Trace (type 11, format 4, class 0) provides an indication that the
   route has propagated through a particular system.  This can be used
   for loop detection, as well as various methods of troubleshooting.
   The data is one internet address, one of the addresses of the system.
   If an arriving route already carries a trace identifying this system,
   and is not an update, it is discarded.  If it is an update, the route
   is purged.

   Trace SHOULD NOT be simply added to every route traversing a system.
   Rather, it should be added (if being used for loop detection) when
   there is a suspicion that a loop has formed.

   When the distance to a destination has increased twice in a row in a
   fairly short period of time, and the number of trace options present
   in the route did not increase as a result of the last update, the RAP
   process should add a trace option identifying itself to the route.
   Effectively, when a loop forms, one router will select itself to be a
   tracer, adding itself and breaking the loop after one more turn.  If
   that fails for some reason, another router will add its trace.  Each



Ullmann                                                        [Page 14]

RFC 1476                          RAP                          June 1993


   router thus depends in the end only on its own trace and will break
   the loop, even if the other routers are using other methods, or
   simply counting-out the route.

3.2.12  AUP

   The AUP (Acceptable Use Policy) option (type 12, format 2, class
   any), tags a route as being useable only according to the policy of a
   network.  This may be used to avoid traversal of the net by (for
   example) commercial traffic, or to prevent un-intentional use of an
   organization's internal net.  (It does not provide a security barrier
   in the sense of forwarding filters, but does provide cooperative
   exchange of information on the useability of a net.)

   The data is a domain name, probably the name of the network, although
   it may be the name of another organization.  E.g., the routers that
   are subject to the NSF AUP might add NSF.NET as the descriptor of
   that policy.

3.2.13  Public

   Public (type 13, format 0, class 2 or 3) marks the route as
   consisting in part of a public broadcast medium.  Examples of a
   public medium are direct radio broadcast or a multi-drop cable in
   which other receivers, not associated with the destination may read
   the traffic.  I.e., a TV cable is a public medium, a LAN within an
   organization is not, even if it can be easily wiretapped.

   This is intended for use by cable TV providers to identify routes
   that should not be used for private communications, in spite of the
   attractively high bandwidth being offered.

4.  Procedure

   Routing information arrives in the RAP process from other peers, from
   (local) static route and interface configuration, and from other
   protocols (e.g., RIP).  The RAP process filters out routes that are
   of no interest (too detailed or too "far away" in the topology) and
   builds an internal database of available routes.

   From this database, it selects routes that are to be active and loads
   them into the IP forwarding database.

   It then advertises those routes to its peers, at a greater distance.







Ullmann                                                        [Page 15]

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]