As per Relevance of the word restriction, we have this rfc below:
Network Working Group R.
Request for Comments: 1476 Process Software
June 1993
RAP: Internet Route Access
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard. Discussion
suggestions for improvement are requested. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
This RFC describes an open distance vector routing protocol for
at all levels of the internet, from isolated LANs to the
routers of an international commercial network provider
Table of
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.
RAP is a general protocol for distributing routing information at
levels of the Internet, from private LANs to the widest-
international carrier networks. It does not distinguish
"interior" and "exterior" routing (except as restricted by
policy), and therefore is not as restricted nor complex as
protocols that have strict level and area definitions in
models
The protocol encourages the widest possible dissemination of
information, aggregating it only when limits of thrust, bandwidth,
administrative policy require it. Thus RAP permits aggressive use
resources to optimize routes where desired, without the
inherent in the simplifications of other models
While RAP uses IPv7 [RFC1475] addressing internally, it is run
both IPv4 and IPv7 networks, and shares routing information
them. A IPv4 router will only be able to activate and
routes that are defined within the local Administrative Domain (AD),
loading the version 4 subset of the address into the local
forwarding database
Ullmann [Page 2]
RFC 1476 RAP June 1993
1.1 Link-State and Distance-
Of the two major classes of routing algorithm, link-state
distance vector, only distance vector seems to scale from the
network (where RIP is existence-proof of its validity) to large
inter-domain policy routing, where the number of links and
exceeds the ability of each router to map the entire network
In between, we have OSPF, an open link state (specifically,
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,
seems reasonable to apply it to the entire range of scales,
a protocol that works automatically on small groups of LANs, but
apply fairly arbitrary policy in the largest networks
This helps model the real world, where networks are not
divided into hierarchical domains with identifiable "border" routers
but have many links across organizational structure and over
fences
1.2
The RAP protocol propagates routes in the opposite direction to
travel of datagrams using the routes. To avoid confusion
the routing protocol, several terms are distinguished
source where datagrams come from, the source of
destination where datagrams go to, the destination of
origin where routing information originates, the
initially inserting route information into
RAP
target where routing information goes, the target uses
information to send
1.3
Protocols should become simpler as they evolve
Ullmann [Page 3]
RFC 1476 RAP June 1993
2. RAP
The RAP protocol operates on TCP port 38, with peers opening
symmetric TCP connection between the RAP ports on each system.
only one RAP connection exists between any pair of peers
RAP is also used on UDP port 38, as a peer discovery method.
(i.e., non-routing systems) may listen to RAP datagrams on this
to discover local gateways. This is in addition to, or in lieu of
an Internet Standard gateway discovery protocol, which does not
at this writing
The peers then use RAP commands to send each other all
available though the sending peer. This occurs as a full-
(i.e., simultaneous) exchange of information, with no
of individual commands
Once the initial exchange has been completed, the peers send
updates to routes, new routes, and purge commands to delete
previously offered
When the connection is broken, each system purges all routes that
been offered by the peer
2.1 Command Header
Each RAP command starts with a header. The header contains a
field to identify the start of the next packet in the TCP stream,
version number, and the code for the command. On UDP, the
field does not appear: each UDP datagram must contain exactly
RAP command and not contain data or padding after the end of
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
The length is a 32 bit unsigned number specifying the offset in
from the first byte of the length field of this command packet to
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
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
considered the limit for senders, and what (larger) size should
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
greater than 16384 bytes. Receivers SHOULD consider packets
appear to be greater than 162144 bytes in length to be an
of an unrecoverable error
Note that these limits probably will not be approached in
operation of version 1 of the protocol; receivers may
decline to use routes described by 16K bytes of metrics and policy
But even the most memory-restricted implementation MUST be able
skip such a command packet
2.1.2 RAP
The version field is a 16 bit unsigned number. It identifies
version of RAP used for that command. Note that commands
different versions may be mixed on the same connection, although
usual procedure will be to do the serious protocol (exchanging
updates) only at the highest version common to both ends of
connection
Each side starts the connection by sending a poll command, using
highest version supported and continues by using the highest
received in any command from the remote. The response to the
will either be a no-operation packet at that version or an
packet at the highest version supported by the remote
This document describes version 1 of the RAP protocol
2.2 RAP
There five simple RAP commands, described in the following sections
2.2.1 No
The no operation command serves to reset the poll timer (see
section) of the receiver, or (as a side effect) to tell the
that a particular version is supported. It never contains
specific data and its length is always 8.
The no operation command is also used in a UDP broadcast to
other systems that the sender is running RAP actively on the
Ullmann [Page 5]
RFC 1476 RAP June 1993
and is both a possible gateway and a candidate peer. If this
is being sent in response to a broadcast poll, it should be sent
to the poller
A RAP process may send such broadcasts in a startup sequence, or
may persist indefinitely to inform other systems coming on line.
it persists, it must not send them more than once every 10
(after the initial startup sequence). If the RAP process sends
as part of its startup, it must not persist in sending them after
startup sequence
The command code for no-operation is always 0, regardless of
version
2.2.2
A poll command packet requests that the other side transmit either
no-operation packet, or some other packet if sent without delay
(i.e., receivers MUST NOT delay a response to a poll by waiting
some other packet expected to be queued soon.)
The poll command code is always 1, regardless of version, and
length is always 8.
Each RAP implementation runs a timer for each connection, to
that if the other system becomes unreachable, the connection will
closed or reset. The timers run at each end of the connection
independent; each system is responsible for sending polls in time
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
directions, polls may not be necessary for long periods of time
the timers are continually reset. When the connection is quiescent
both timers will typically get reset as a result of the side with
shorter timer doing a poll, and then getting a no-operation
response. RAP implementations MUST NOT be dependent in any way
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
or in addition to a timer. However, the use of TCP keepalives
discouraged, and this procedure does not ensure that the remote
process is alive, only that its TCP is accepting data. Thus
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
range 1 to 10 minutes on a per-peer basis, and MAY be
(disabled) by explicit configuration
On UDP, a system (router or non-routing host) may send RAP polls
attempt to locate candidate peers or possible gateways. Such
system must not persist in sending polls after its startup sequence
except that a system which actually has offered traffic for non-
destinations, and has no available gateways, may continue to
periodic polls to attempt to acquire a gateway
2.2.3
The error packet is used to report an error, whether fatal,
or informational. It includes a null terminated text description
ISO-10646-UTF-1 of the condition, which may be useful to a
administrator, and SHOULD be written to a log file. (The machine
not expected to understand the text.)
Errors are actual failures (in the interpretation of the receiver)
use the correct syntax and semantics of the RAP protocol itself,
"failure" of the receiver to implement a version of the protocol
Other conditions that may require action on the part of the
(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
desires the condition to be fatal (unrecoverable), its proper
is to close the connection. This requirement is to prevent the
of failure mode demonstrated by hosts that killed off TCP
on the receipt of ICMP Host-Unreachable notifications, even when
condition is transient. We do not want to discourage the
of errors, in the way that some implementations avoided sending
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 (
might be) an error packet itself. Subsequent versions of RAP
keep the command code point (2) of the error packet
2.2.4 Add
The add route command offers a route to the receiving peer. As
later, it MUST be a route actually loaded into the
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
metrics and other options (such as policies) associated with
route
Distance is a simple count of the hops to the RAP process (or
routing process) that originated the route, incremented every
the route is forwarded. Its initial value may be greater than 1,
particularily for a route that is administratively configured
aggregate routes for a large network or AD. It may also enter
RAP routing domain for the first time with a non-zero
because the route originated in RIP, OSPF, or BGP; if so,
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
binary representation of the network mask. Non-contiguous masks
not supported directly. (The destination restriction option may
used to give another, non-contiguous, mask; the header mask
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
on the sending host can use to rapidly identify the route and
next hop for each incoming datagram. The host receiving the
places this identifier into the forward route ID field of
datagrams being sent to this host
The route ID is also used to uniquely identify the route in the
route operation
2.2.5 Purge
The purge route command requires that the receiving peer delete
route from its database if in use, and requires that it revoke
route from any of its peers to whom it has offered the route.
command should preferably be sent before the route is deleted
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
any added metrics or options
If the route identifier in a purge route command is zero, the
requires the deletion of all routes to the destination
offered by this peer
3. Attributes of
There are a rather large number of possible attributes
Possibilities include both metrics, and other options describing
example policy restrictions and alterations of proximity.
particular route will usefully carry only a few attributes or none
all, particularily on an infrastructure backbone. A
policy for the routers that make up a backbone might be to strip
attributes before propagating routes (discarding routes that
attributes with class indications prohibiting this), and then
(for example) an AUP attribute to all routes propagated off of
backbone. A less drastic method would be to simply prefer
with no restrictions, but still propagate a route with
if no other is available
Most options can occur more than once in a route if there is
sensible reason to do so
Ullmann [Page 9]
RFC 1476 RAP June 1993
3.1 Metric and Option
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
A description of each field
length length of the option or
C option class, see
format data
type option type
data variable
3.1.1 Option
This field tells implementations what to do with routes
options or metrics they do not understand. No implementation
required to implement (i.e., understand) any given option or
by the RAP specification itself, except for the distance metric
the RAP header
Classes
0 use, propagate, and include this option
1 use, propagate, but do not include this
2 use this route, but do not propagate
3 discard this
Note that class 0 is an imperative: if the route is propagated,
option must be included
Class and type are entirely orthogonal, different
might use different classes for the same option or metric
3.1.2
The type code identifies the specific option or metric. The
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
zero, but an implementation that "understands" the null option
decline to propagate it
Note that since an implementation may delete an option of class 1
simply setting its type to 0 and forwarding the route description
class 1 does not provide any confidentiality of the content of
option
3.1.3
The format field specifies the format of the data included after
option header. Formats
0 none, no data present
1 one or more 32-bit signed
2 a character string, null
3 one or more real
4 an octet
5 one real, followed by a character
Format is also orthogonal to type, but a particular type is
only reasonably represented by one format. This allows decoding
all option values for logging and other troubleshooting, even
the option type is unknown. (A new unknown format will still
a problem.)
Format 4, octet string, is to be represented in dotted-decimal
form when printed; it is normally an internet address
Format 5 is intended for dimensioned parameters with the
string giving the dimension or scale
3.2 Metrics and
As much as possible, metrics are kept in the base units of bytes
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
multiple of 8 that isn't part of what one would come to expect from
decimal metric system that uses the other prefixes. However, since
(kilo) is often taken to be 1024, and M (mega) to be 1,048,576 (
even 1,024,000) we allow this liberty
Distance is measured in units also unique to the field. It is
integer number of times that a datagram must be forwarded to
the destination. (Hop count.)
Ullmann [Page 11]
RFC 1476 RAP June 1993
3.2.1
The Distance metric counts the number of hops on a route; this
included in the RAP route command header
The initial distance at insertion into the RAP domain by the
of the route MUST be less than or equal to 2z, where z is the
of zero bits in the route mask
If the origin derives the route from RIP or OSPF, and the
exceeds 2z, the route must not be used
When a router originates a route designed to permit aggregation,
distance is usefully set to more than 0; this allows simple
aggregation without propagating small distance changes repeatedly
the internal diameter of the described network changes
For example, for routers designated to announce a default route
an AD, with a 24/48 mask, the maximum initial distance is 96.
3.2.2
The Delay metric (Type = 2) measures the one-way path delay. It
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
The MTU metric (Type = 3) measures the minimum value over the
of the Maximum Transmission Unit, i.e., the largest IP datagram
can be routed without resulting in fragmentation
Format is one integer, measuring the MTU in bytes
3.2.4
The Bandwidth metric (Type = 4) measures the minimum bandwidth of
path segments that make up the route
Format is one real, representing bandwidth in bytes/second
3.2.5
The origin attribute (type = 5) identifies the router that
inserted the route into the RAP domain. It is one of the
addresses of the router, format is 4.
Ullmann [Page 12]
RFC 1476 RAP June 1993
3.2.6
The target attribute (type = 6) identifies a host or network
which the route should be propagated, regardless of
filtering that would otherwise occur. This aids in the
of tunnels for hosts or subnets "away from home." It can be used
force the route to propagate all the way to the home network, or
try to propagate a better route to a host that the origin
established a connection (e.g., TCP) with. Note that a router
distinguish these two cases during proximity filtering by
the route described with the host or network identified by the
option
Format is 4.
3.2.7 Packet
The packet cost metric (type = 7) measures the actual cost (
someone) of sending data over the route. It is probably either
3 or 0. Format is 5.
The real number is the cost in currency units/byte. Tariffs set
packets or "segments" should be converted using the nominal (
actual path) size. For example, Sprintnet charges for
connections within its network are US$1.40/Ksegment thus for
of 64 bytes, the cost is 0.000021875 USD
The string is the 3 capital letter ISO code [ISO4217] for
currency used. Funds codes and codes XAU, XBA, XBB, XBC, XBD,
XXX are not used
If a route already has a packet cost in a different
associated with it, another instance of this option should be added
RAP implementations MUST NOT attempt to convert the currency
except when actually making a route selection decision. That is,
effects of a currency conversion should never be propagated,
for the proper effect of such a selection decision
3.2.8 Time
The time cost metric (type = 8) measures the actual cost of
one or more paths in the route open to send data. It is
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
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
also apply
3.2.9 Source
A source restriction option (type 9, format 4, class 2 or 3)
indicates that a route may only be used by datagrams from
particular source or set of sources. The data consists of a
or host number, and a mask to qualify it. If multiple
restriction options are included, the restriction is the
union of the sources specified; i.e., any are permitted
Source restrictions must be added to routes when the RAP system
security filters set in the IP forwarding layer. This is
to prevent datagrams from taking "better" routes that end in
datagram being silently discarded at the filter. Note that
propagates confidential information about the security configuration
but only toward the net authorized to use the route if the
implementation is careful about where it is propagated
3.2.10 Destination
A destination restriction option (type 10, format 4, class 3)
only to provide a non-contiguous mask, the destination already
been specified in the command header. Data is the
network and mask
3.2.11
Trace (type 11, format 4, class 0) provides an indication that
route has propagated through a particular system. This can be
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
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)
there is a suspicion that a loop has formed
When the distance to a destination has increased twice in a row in
fairly short period of time, and the number of trace options
in the route did not increase as a result of the last update, the
process should add a trace option identifying itself to the route
Effectively, when a loop forms, one router will select itself to be
tracer, adding itself and breaking the loop after one more turn.
that fails for some reason, another router will add its trace.
Ullmann [Page 14]
RFC 1476 RAP June 1993
router thus depends in the end only on its own trace and will
the loop, even if the other routers are using other methods,
simply counting-out the route
3.2.12
The AUP (Acceptable Use Policy) option (type 12, format 2,
any), tags a route as being useable only according to the policy of
network. This may be used to avoid traversal of the net by (
example) commercial traffic, or to prevent un-intentional use of
organization's internal net. (It does not provide a security
in the sense of forwarding filters, but does provide
exchange of information on the useability of a net.)
The data is a domain name, probably the name of the network,
it may be the name of another organization. E.g., the routers
are subject to the NSF AUP might add NSF.NET as the descriptor
that policy
3.2.13
Public (type 13, format 0, class 2 or 3) marks the route
consisting in part of a public broadcast medium. Examples of
public medium are direct radio broadcast or a multi-drop cable
which other receivers, not associated with the destination may
the traffic. I.e., a TV cable is a public medium, a LAN within
organization is not, even if it can be easily wiretapped
This is intended for use by cable TV providers to identify
that should not be used for private communications, in spite of
attractively high bandwidth being offered
4.
Routing information arrives in the RAP process from other peers,
(local) static route and interface configuration, and from
protocols (e.g., RIP). The RAP process filters out routes that
of no interest (too detailed or too "far away" in the topology)
builds an internal database of available routes
From this database, it selects routes that are to be active and
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
|
[proximity filtering/aggregation] [static routes
| |
v
[route database] ---> [selected active routes
^ |
|
[RIP, etc. routes] [output filtering
|
[routes advertised
-------------------------------------------------------------------
4.1 Receiver
The first step is to filter out offered routes that are too "
away" or too specific. The filter consists of a maximum distance
which a route is considered usable for each possible (contiguous
mask
Routers that need universal connectivity must either pass through
filter all routes regardless of distance (short of "infinity"),
use aggregation to reduce them, or have a default route to a
that does this
The filter may be adjusted dynamically to fit limited resources,
if the filter is opened, i.e., made less restrictive, there may
routes that have already been offered and discarded that will
become available
4.2 Update of metrics and
The process then updates any metrics present on the route to
the path to the RAP peer. MTU and bandwidth are minimized, delay
cost are added in. Distance is incremented. Any unknown
cause class-dependent processing: discarding the option (class 2)
route (3), or marking the route as non-propagatable (1).
Policy options that are known may cause the route to be discarded
this stage
Ullmann [Page 16]
RFC 1476 RAP June 1993
4.3
The next step is to aggregate routes that are subsetted by
routes through the same peer. This should not be done
in every possible case. The more information that is propagated,
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
propagated further, if it is through the same peer (next hop) and
a smaller distance metric than the containing route. (Thus
will always travel "downhill" as they take more specific routes.)
The usual case of aggregation is that routes derived from
configurations on the routers from which they originated are
into routes offered by routers explicitly configured to route for
entire network, area, or AD. If the larger area becomes partitioned
unaggregatable routes will appear (as routes outside the area
the shortest distance routes) and traffic will flow around
partition
Attributes of routes, particularily policy options, may
aggregation and may result in routes simply being discarded
Some information about aggregation also needs to be represented
the forwarding database, if the route is made active: the
will need to make a decision as to which forward route identifier
use for each datagram arriving on the active route
4.4 Active route
The router selects those routes to be entered into the IP
database and actively used to forward datagrams from the set
routes after aggregation, combined with routes derived from
protocols such as RIP. This selection may be made on any
of attributes and options desired by local policy
4.5 Transmitter
Finally, the RAP process must decide which routes to offer to
peers. These must be a subset of the active routes, and may in
be a selected subset for each peer. Arbitrary local policies may
used in deciding whether or not to offer any particular route to
given peer
However, the transmitter must ensure that any datagram filters
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
RAP is designed to support many different kinds of routing
algorithms, and allow them to interact to varying extents.
can be shared among administrations, and between systems managed
more or less sophistication
This leaves one absolute requirement: routing loops must be self
healing, regardless of the algorithm used on each host. There
two caveats
1. A loop will not fix itself in the presence of an error
continually recurs (thus re-generating the loop
2. The last resort algorithm does not provide rapid breaking
loops, only eventual breaking of them even in the absence
any intervention by (human) intelligence
The algorithm relies on the distance in the RAP route header.
count must be updated (i.e., incremented by one) at each
forwarding the route
Routers must also impose some limit on the number of hops
in incoming routes, discarding any routes that exceed the limit
This limit is "infinity" in the classic algorithm. In RIP,
is 15, much too low for general inter-domain routing
In RAP, infinity is defined as 2z + i, where z is the number of
bits in the mask (as described previously) and i is a small
which MUST be configurable
Note that RAP depends on the last resort algorithm, "counting
infinity," much less than predecessors such as RIP. Routes in
RAP domain will usually be purged from the net as the purge
command is flooded without the delays typical of periodic
algorithms. Only in some cases will loops form, and they will
counted out as fast as the routing processes can exchange
information
5.
Unlike prior routing protocols, RAP is designed to solve the
problem, from hands-off autoconfiguration of LAN networks,
implementing the most complex policies of international carriers.
provides a scaleable solution to carry the Internet forward to
future in which essentially all users of data transmission use IP
the fabric of their networks
Ullmann [Page 18]
RFC 1476 RAP June 1993
6. Appendix: Real Number
Real numbers are represented by a one byte exponent, e, in excess-128
notation, and a fraction, f, in excess-8388608 notation, with
radix point at the right. (I.e., the "fraction" is actually
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
representation will, of course, provide more accuracy for numbers
exactly representable
Example code, in C
#include
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.
[ISO3166] International Organization for Standardization.
for the Representation of Names of Countries.
3166, ISO, 1988.
[ISO4217] International Organization for Standardization.
for the representation of currencies and funds.
4217, ISO, 1981.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet
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.,
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
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
Security issues are discussed in sections 3.2.9 and 3.2.12.
9. Author's
Robert
Process Software
959 Concord
Framingham, MA 01701
Phone: +1 508 879 6994 x226
Email: Ariel@Process.
Ullmann [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
