rfc1476.txt

RFC 的详细文档！

Ullmann                                                         [Page 5]

RFC 1476                          RAP                          June 1993


   and is both a possible gateway and a candidate peer.  If this command
   is being sent in response to a broadcast poll, it should be sent only
   to the poller.

   A RAP process may send such broadcasts in a startup sequence, or it
   may persist indefinitely to inform other systems coming on line.  If
   it persists, it must not send them more than once every 10 minutes
   (after the initial startup sequence).  If the RAP process sends polls
   as part of its startup, it must not persist in sending them after the
   startup sequence.

   The command code for no-operation is always 0, regardless of RAP
   version.

2.2.2  Poll

   A poll command packet requests that the other side transmit either a
   no-operation packet, or some other packet if sent without delay.
   (i.e., receivers MUST NOT delay a response to a poll by waiting for
   some other packet expected to be queued soon.)

   The poll command code is always 1, regardless of version, and the
   length is always 8.

   Each RAP implementation runs a timer for each connection, to ensure
   that if the other system becomes unreachable, the connection will be
   closed or reset.  The timers run at each end of the connection are
   independent; each system is responsible for sending polls in time to
   reset its own timer.

   The timer MUST be reset (restarted) on the receipt of any RAP packet,
   regardless of whether the version or command code is known.

   In normal operation, if route updates are being sent in both
   directions, polls may not be necessary for long periods of time as
   the timers are continually reset.  When the connection is quiescent,
   both timers will typically get reset as a result of the side with the
   shorter timer doing a poll, and then getting a no-operation in
   response.  RAP implementations MUST NOT be dependent in any way on
   the size or existence of the remote timer.

   An implementation that has access to information from the TCP layer,
   such as the results of TCP layer keepalives, MAY use this instead of
   or in addition to a timer.  However, the use of TCP keepalives is
   discouraged, and this procedure does not ensure that the remote RAP
   process is alive, only that its TCP is accepting data.  Thus a
   failure mode exists that would not exist for active RAP layer polls.




Ullmann                                                         [Page 6]

RFC 1476                          RAP                          June 1993


   The timer MUST be implemented, SHOULD be configurable in at least the
   range 1 to 10 minutes on a per-peer basis, and MAY be infinite
   (disabled) by explicit configuration.

   On UDP, a system (router or non-routing host) may send RAP polls to
   attempt to locate candidate peers or possible gateways.  Such a
   system must not persist in sending polls after its startup sequence,
   except that a system which actually has offered traffic for non-local
   destinations, and has no available gateways, may continue to send
   periodic polls to attempt to acquire a gateway.

2.2.3  Error

   The error packet is used to report an error, whether fatal, serious
   or informational.  It includes a null terminated text description in
   ISO-10646-UTF-1 of the condition, which may be useful to a human
   administrator, and SHOULD be written to a log file.  (The machine is
   not expected to understand the text.)

   Errors are actual failures (in the interpretation of the receiver) to
   use the correct syntax and semantics of the RAP protocol itself, or
   "failure" of the receiver to implement a version of the protocol.
   Other conditions that may require action on the part of the peer
   (such as purging a route) are given their own command codes.

     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 (2)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        error code (0)  [reserved]                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        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]