rfc1476.txt

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

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        description                                            |
    +                                                               +
    |                       ...                                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RAP system receiving an Error packet MUST NOT regard it as fatal,
   and close the connection or discard routes.  If the sending system
   desires the condition to be fatal (unrecoverable), its proper action
   is to close the connection.  This requirement is to prevent the kind
   of failure mode demonstrated by hosts that killed off TCP connections
   on the receipt of ICMP Host-Unreachable notifications, even when the
   condition is transient.  We do not want to discourage the reporting
   of errors, in the way that some implementations avoided sending ICMP
   datagrams to deal with overly sensitive hosts.



Ullmann                                                         [Page 7]

RFC 1476                          RAP                          June 1993


   An error packet MUST NOT be sent in response to something that is (or
   might be) an error packet itself.  Subsequent versions of RAP should
   keep the command code point (2) of the error packet.

2.2.4  Add Route

   The add route command offers a route to the receiving peer.  As noted
   later, it MUST be a route actually loaded into the forwarding
   database of the offering peer at the time the add route is sent.

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        length                                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        RAP version (1)        |       command code (3)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        distance               |     (MBZ)     |     mask      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        destination network                                    |
    +                                                               +
    |                    ...                                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        route identifier                                       |
    +                                                               +
    |                    ...                                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        metrics and options    ....                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The add route command describes a single offered route, with the
   metrics and other options (such as policies) associated with the
   route.

   Distance is a simple count of the hops to the RAP process (or other
   routing process) that originated the route, incremented every time
   the route is forwarded.  Its initial value may be greater than 1,
   particularily for a route that is administratively configured to
   aggregate routes for a large network or AD.  It may also enter the
   RAP routing domain for the first time with a non-zero distance
   because the route originated in RIP, OSPF, or BGP; if so, the
   distance carried in that protocol is copied into the RAP route.

   The mask is a count of the number of bits of prefix ones in the
   binary representation of the network mask.  Non-contiguous masks are
   not supported directly.  (The destination restriction option may be
   used to give another, non-contiguous, mask; the header mask would
   then describes the number of contiguous ones.)



Ullmann                                                         [Page 8]

RFC 1476                          RAP                          June 1993


   The route identifier is a 64 bit value that the IP forwarding module
   on the sending host can use to rapidly identify the route and the
   next hop for each incoming datagram.  The host receiving the route
   places this identifier into the forward route ID field of the
   datagrams being sent to this host.

   The route ID is also used to uniquely identify the route in the purge
   route operation.

2.2.5  Purge Route

   The purge route command requires that the receiving peer delete a
   route from its database if in use, and requires that it revoke that
   route from any of its peers to whom it has offered the route.  This
   command should preferably be sent before the route is deleted from
   the sending peer's forwarding database, but this is not (cannot be)
   required; it should be sent without delay when the route is removed.

   The command code is 4.  The format is the same as add route without
   any added metrics or options.

   If the route identifier in a purge route command is zero, the command
   requires the deletion of all routes to the destination previously
   offered by this peer.

3.  Attributes of Routes

   There are a rather large number of possible attributes.
   Possibilities include both metrics, and other options describing for
   example policy restrictions and alterations of proximity.  Any
   particular route will usefully carry only a few attributes or none at
   all, particularily on an infrastructure backbone.  A reasonable
   policy for the routers that make up a backbone might be to strip all
   attributes before propagating routes (discarding routes that carry
   attributes with class indications prohibiting this), and then adding
   (for example) an AUP attribute to all routes propagated off of the
   backbone.  A less drastic method would be to simply prefer routes
   with no restrictions, but still propagate a route with restrictions
   if no other is available.

   Most options can occur more than once in a route if there is any
   sensible reason to do so.









Ullmann                                                         [Page 9]

RFC 1476                          RAP                          June 1993


3.1  Metric and Option Format

   Each metric or option for a route begins with a 32 bit header:

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   length      | C |  format   |           type                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        option data                 ...        |   padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   RAP Option/Metric Header Format

A description of each field:

   length       length of the option or metric
   C            option class, see below
   format       data format
   type         option type identifier
   data         variable length

3.1.1  Option Class

   This field tells implementations what to do with routes containing
   options or metrics they do not understand.  No implementation is
   required to implement (i.e., understand) any given option or metric
   by the RAP specification itself, except for the distance metric in
   the RAP header.

   Classes:

   0        use, propagate, and include this option unmodified
   1        use, propagate, but do not include this option
   2        use this route, but do not propagate it
   3        discard this route

   Note that class 0 is an imperative:  if the route is propagated, the
   option must be included.

   Class and type are entirely orthogonal, different implementations
   might use different classes for the same option or metric.

3.1.2  Type

   The type code identifies the specific option or metric.  The codes
   are part of the option descriptions following.




Ullmann                                                        [Page 10]

RFC 1476                          RAP                          June 1993


   Type 0 indicates a null (no-operation) option.  It should be class
   zero, but an implementation that "understands" the null option may
   decline to propagate it.

   Note that since an implementation may delete an option of class 1 by
   simply setting its type to 0 and forwarding the route description,
   class 1 does not provide any confidentiality of the content of an
   option.

3.1.3  Format

   The format field specifies the format of the data included after the
   option header.  Formats:

   0        none, no data present.
   1        one or more 32-bit signed integers
   2        a character string, null terminated
   3        one or more real numbers
   4        an octet string
   5        one real, followed by a character string

   Format is also orthogonal to type, but a particular type is usually
   only reasonably represented by one format.  This allows decoding of
   all option values for logging and other troubleshooting, even when
   the option type is unknown.  (A new unknown format will still present
   a problem.)

   Format 4, octet string, is to be represented in dotted-decimal byte
   form when printed; it is normally an internet address.

   Format 5 is intended for dimensioned parameters with the character
   string giving the dimension or scale.

3.2  Metrics and Options

   As much as possible, metrics are kept in the base units of bytes and
   seconds, by analogy to the physics systems of MKS (meter-kilogram-
   second) and CGS (centimeter-gram-second) of base units.

   Bytes aren't the real primitive, the bit is.  We are thus using a
   multiple of 8 that isn't part of what one would come to expect from a
   decimal metric system that uses the other prefixes.  However, since K
   (kilo) is often taken to be 1024, and M (mega) to be 1,048,576 (or
   even 1,024,000) we allow this liberty.

   Distance is measured in units also unique to the field.  It is the
   integer number of times that a datagram must be forwarded to reach
   the destination.  (Hop count.)



Ullmann                                                        [Page 11]

RFC 1476                          RAP                          June 1993


3.2.1  Distance

   The Distance metric counts the number of hops on a route; this is
   included in the RAP route command header.

   The initial distance at insertion into the RAP domain by the origin
   of the route MUST be less than or equal to 2z, where z is the number
   of zero bits in the route mask.

   If the origin derives the route from RIP or OSPF, and the distance
   exceeds 2z, the route must not be used.

   When a router originates a route designed to permit aggregation, the
   distance is usefully set to more than 0; this allows simple subset
   aggregation without propagating small distance changes repeatedly as
   the internal diameter of the described network changes.

   For example, for routers designated to announce a default route for
   an AD, with a 24/48 mask, the maximum initial distance is 96.

3.2.2  Delay

   The Delay metric (Type = 2) measures the one-way path delay.  It is
   usually the sum of delays configured for the gateways and interfaces,
   but might also include path segments that are actually measured.

   Format is real (3), with one value.  The units are seconds.

3.2.3  MTU

   The MTU metric (Type = 3) measures the minimum value over the route
   of the Maximum Transmission Unit, i.e., the largest IP datagram that
   can be routed without resulting in fragmentation.

   Format is one integer, measuring the MTU in bytes.

3.2.4  Bandwidth

   The Bandwidth metric (Type = 4) measures the minimum bandwidth of the
   path segments that make up the route.

   Format is one real, representing bandwidth in bytes/second.

3.2.5  Origin

   The origin attribute (type = 5) identifies the router that originally
   inserted the route into the RAP domain.  It is one of the IP
   addresses of the router, format is 4.



Ullmann                                                        [Page 12]

RFC 1476                          RAP                          June 1993


3.2.6  Target

   The target attribute (type = 6) identifies a host or network toward
   which the route should be propagated, regardless of proximity
   filtering that would otherwise occur.  This aids in the establishment
   of tunnels for hosts or subnets "away from home." It can be used to
   force the route to propagate all the way to the home network, or to
   try to propagate a better route to a host that the origin has
   established a connection (e.g., TCP) with.  Note that a router can
   distinguish these two cases during proximity filtering by comparing
   the route described with the host or network identified by the target
   option.

   Format is 4.

3.2.7  Packet Cost

   The packet cost metric (type = 7) measures the actual cost (to
   someone) of sending data over the route.  It is probably either class
   3 or 0.  Format is 5.

   The real number is the cost in currency units/byte.  Tariffs set in
   packets or "segments" should be converted using the nominal (or
   actual path) size.  For example, Sprintnet charges for DAF
   connections within its network are US$1.40/Ksegment thus for segments
   of 64 bytes, the cost is 0.000021875 USD.

   The string is the 3 capital letter ISO code [ISO4217] for the
   currency used.  Funds codes and codes XAU, XBA, XBB, XBC, XBD, and
   XXX are not used.

   If a route already has a packet cost in a different currency
   associated with it, another instance of this option should be added.
   RAP implementations MUST NOT attempt to convert the currency units
   except when actually making a route selection decision.  That is, the
   effects of a currency conversion should never be propagated, except
   for the proper effect of such a selection decision.

3.2.8  Time Cost

   The time cost metric (type = 8) measures the actual cost of holding
   one or more paths in the route open to send data.  It is probably
   either class 3 or 0.  Format is 5.

   The real number is the cost in currency units/second.  For example,
   Sprintnet charges for international connections (to typical
   destinations) are US$10/hour so the cost is 0.002777778 USD.




Ullmann                                                        [Page 13]

RFC 1476                          RAP                          June 1993


   The other notes re codes used and conversions in the previous section
   also apply.

3.2.9  Source Restriction

   A source restriction option (type 9, format 4, class 2 or 3)
   indicates that a route may only be used by datagrams from a
   particular source or set of sources.  The data consists of a network
   or host number, and a mask to qualify it.  If multiple source
   restriction options are included, the restriction is the logical
   union of the sources specified; i.e., any are permitted.

   Source restrictions must be added to routes when the RAP system has
   security filters set in the IP forwarding layer.  This is necessary
   to prevent datagrams from taking "better" routes that end in the
   datagram being silently discarded at the filter.  Note that this