rfc1476.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        R. Ullmann
Request for Comments: 1476                 Process Software Corporation
                                                              June 1993


                  RAP: Internet Route Access Protocol

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Abstract

   This RFC describes an open distance vector routing protocol for use
   at all levels of the internet, from isolated LANs to the major
   routers of an international commercial network provider.

Table of Contents

   1.       Introduction  . . . . . . . . . . . . . . . . . . . 2
   1.1       Link-State and Distance-Vector . . . . . . . . . . 3
   1.2       Terminology  . . . . . . . . . . . . . . . . . . . 3
   1.3       Philosophy . . . . . . . . . . . . . . . . . . . . 3
   2.       RAP Protocol  . . . . . . . . . . . . . . . . . . . 4
   2.1       Command Header Format  . . . . . . . . . . . . . . 4
   2.1.1     Length field . . . . . . . . . . . . . . . . . . . 4
   2.1.2     RAP version  . . . . . . . . . . . . . . . . . . . 5
   2.2       RAP Commands . . . . . . . . . . . . . . . . . . . 5
   2.2.1     No operation . . . . . . . . . . . . . . . . . . . 5
   2.2.2     Poll . . . . . . . . . . . . . . . . . . . . . . . 6
   2.2.3     Error  . . . . . . . . . . . . . . . . . . . . . . 7
   2.2.4     Add Route  . . . . . . . . . . . . . . . . . . . . 8
   2.2.5     Purge Route  . . . . . . . . . . . . . . . . . . . 9
   3.       Attributes of Routes  . . . . . . . . . . . . . . . 9
   3.1       Metric and Option Format . . . . . . . . . . . . .10
   3.1.1     Option Class . . . . . . . . . . . . . . . . . .  10
   3.1.2     Type . . . . . . . . . . . . . . . . . . . . . .  10
   3.1.3     Format . . . . . . . . . . . . . . . . . . . . .  11
   3.2       Metrics and Options  . . . . . . . . . . . . . .  11
   3.2.1     Distance . . . . . . . . . . . . . . . . . . . .  12
   3.2.2     Delay  . . . . . . . . . . . . . . . . . . . . .  12
   3.2.3     MTU  . . . . . . . . . . . . . . . . . . . . . .  12
   3.2.4     Bandwidth  . . . . . . . . . . . . . . . . . . .  12



Ullmann                                                         [Page 1]

RFC 1476                          RAP                          June 1993


   3.2.5     Origin . . . . . . . . . . . . . . . . . . . . .  12
   3.2.6     Target . . . . . . . . . . . . . . . . . . . . .  13
   3.2.7     Packet Cost  . . . . . . . . . . . . . . . . . .  13
   3.2.8     Time Cost  . . . . . . . . . . . . . . . . . . .  13
   3.2.9     Source Restriction . . . . . . . . . . . . . . .  14
   3.2.10    Destination Restriction  . . . . . . . . . . . .  14
   3.2.11    Trace  . . . . . . . . . . . . . . . . . . . . .  14
   3.2.12    AUP  . . . . . . . . . . . . . . . . . . . . . .  15
   3.2.13    Public . . . . . . . . . . . . . . . . . . . . .  15
   4.       Procedure   . . . . . . . . . . . . . . . . . . .  15
   4.1       Receiver filtering . . . . . . . . . . . . . . .  16
   4.2       Update of metrics and options  . . . . . . . . .  16
   4.3       Aggregation  . . . . . . . . . . . . . . . . . .  17
   4.4       Active route selection . . . . . . . . . . . . .  17
   4.5       Transmitter filtering  . . . . . . . . . . . . .  17
   4.6       Last resort loop prevention  . . . . . . . . . .  18
   5.       Conclusion  . . . . . . . . . . . . . . . . . . .  18
   6.       Appendix: Real Number Representation  . . . . . .  19
   7.       References  . . . . . . . . . . . . . . . . . . .  20
   8.       Security Considerations . . . . . . . . . . . . .  20
   9.       Author's Address  . . . . . . . . . . . . . . . .  20

1.  Introduction

   RAP is a general protocol for distributing routing information at all
   levels of the Internet, from private LANs to the widest-flung
   international carrier networks.  It does not distinguish between
   "interior" and "exterior" routing (except as restricted by specific
   policy), and therefore is not as restricted nor complex as those
   protocols that have strict level and area definitions in their
   models.

   The protocol encourages the widest possible dissemination of topology
   information, aggregating it only when limits of thrust, bandwidth, or
   administrative policy require it.  Thus RAP permits aggressive use of
   resources to optimize routes where desired, without the restrictions
   inherent in the simplifications of other models.

   While RAP uses IPv7 [RFC1475] addressing internally, it is run over
   both IPv4 and IPv7 networks, and shares routing information between
   them.  A IPv4 router will only be able to activate and propagate
   routes that are defined within the local Administrative Domain (AD),
   loading the version 4 subset of the address into the local IP
   forwarding database.







Ullmann                                                         [Page 2]

RFC 1476                          RAP                          June 1993


1.1  Link-State and Distance-Vector

   Of the two major classes of routing algorithm, link-state and
   distance vector, only distance vector seems to scale from the local
   network (where RIP is existence-proof of its validity) to large scale
   inter-domain policy routing, where the number of links and policies
   exceeds the ability of each router to map the entire network.

   In between, we have OSPF, an open link state (specifically, using
   shortest-path-first analysis of the graph, hence the acronym)
   protocol, with extensive development in intra-area routing.

   Since distance vector has proven useful at both ends of the range, it
   seems reasonable to apply it to the entire range of scales, creating
   a protocol that works automatically on small groups of LANs, but can
   apply fairly arbitrary policy in the largest networks.

   This helps model the real world, where networks are not clearly
   divided into hierarchical domains with identifiable "border" routers,
   but have many links across organizational structure and over back
   fences.

1.2  Terminology

   The RAP protocol propagates routes in the opposite direction to the
   travel of datagrams using the routes.  To avoid confusion explaining
   the routing protocol, several terms are distinguished:

   source          where datagrams come from, the source of the
                   datagrams

   destination     where datagrams go to, the destination of the
                   datagrams

   origin          where routing information originates, the router
                   initially inserting route information into the
                   RAP domain

   target          where routing information goes, the target uses the
                   information to send datagrams

1.3  Philosophy

   Protocols should become simpler as they evolve.







Ullmann                                                         [Page 3]

RFC 1476                          RAP                          June 1993


2.  RAP Protocol

   The RAP protocol operates on TCP port 38, with peers opening a
   symmetric TCP connection between the RAP ports on each system.  Thus
   only one RAP connection exists between any pair of peers.

   RAP is also used on UDP port 38, as a peer discovery method.  Hosts
   (i.e., non-routing systems) may listen to RAP datagrams on this port
   to discover local gateways.  This is in addition to, or in lieu of,
   an Internet Standard gateway discovery protocol, which does not exist
   at this writing.

   The peers then use RAP commands to send each other all routes
   available though the sending peer.  This occurs as a full-duplex
   (i.e., simultaneous) exchange of information, with no acknowledgement
   of individual commands.

   Once the initial exchange has been completed, the peers send only
   updates to routes, new routes, and purge commands to delete routes
   previously offered.

   When the connection is broken, each system purges all routes that had
   been offered by the peer.

2.1  Command Header Format

   Each RAP command starts with a header.  The header contains a length
   field to identify the start of the next packet in the TCP stream, a
   version number, and the code for the command.  On UDP, the length
   field does not appear:  each UDP datagram must contain exactly one
   RAP command and not contain data or padding after the end of the
   command.

     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            |       command code            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1  Length field

   The length is a 32 bit unsigned number specifying the offset in bytes
   from the first byte of the length field of this command packet to the
   start of the length field of the next.  The minimum value is 8.
   There is no specific limit to the length of a command packet;
   implementations MUST be able to at least count and skip over a packet



Ullmann                                                         [Page 4]

RFC 1476                          RAP                          June 1993


   that is too large and then MAY send an error indication.

   Each version of the protocol will profile what size should be
   considered the limit for senders, and what (larger) size should be
   considered by receivers to mean that the connection is insane:
   either unsynchronized or worse.

   For version 1 of the protocol, senders MUST NOT send command packets
   greater than 16384 bytes.  Receivers SHOULD consider packets that
   appear to be greater than 162144 bytes in length to be an indication
   of an unrecoverable error.

   Note that these limits probably will not be approached in normal
   operation of version 1 of the protocol; receivers may reasonably
   decline to use routes described by 16K bytes of metrics and policy.
   But even the most memory-restricted implementation MUST be able to
   skip such a command packet.

2.1.2  RAP version

   The version field is a 16 bit unsigned number.  It identifies the
   version of RAP used for that command.  Note that commands with
   different versions may be mixed on the same connection, although the
   usual procedure will be to do the serious protocol (exchanging route
   updates) only at the highest version common to both ends of the
   connection.

   Each side starts the connection by sending a poll command, using the
   highest version supported and continues by using the highest version
   received in any command from the remote.  The response to the poll
   will either be a no-operation packet at that version or an error
   packet at the highest version supported by the remote.

   This document describes version 1 of the RAP protocol.

2.2  RAP Commands

   There five simple RAP commands, described in the following sections.

2.2.1  No operation

   The no operation command serves to reset the poll timer (see next
   section) of the receiver, or (as a side effect) to tell the receiver
   that a particular version is supported.  It never contains option
   specific data and its length is always 8.

   The no operation command is also used in a UDP broadcast to inform
   other systems that the sender is running RAP actively on the network



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]                             |