is used today to control routes.
- A packet entering the AR is directed to the "near" Server inside
the AR, which performs the functions of the Policy Gateway and
then resends the packet. This may require the use of a regular
source route in some cases, but can probably just be done by
rewriting the destination IP address in the packet. (Note that
the IP PR option proposed in the Appendix has fields for the
original IP source and destination, so that these fields can be
reused in forwarding the packet from gateway to gateway.)
To deal with the lack of host support for the PR option, we again
make use of the Server. Since the Server is the recipient of all
routing information coming into the AR (since it has been set up as
the neighbor of the current gateway at the actual AR boundary) it
alone knows the proper routes out. Internally, it advertises itself
as the default gateway to all networks outside the AR, so that it
receives all the packets intending to leave the region. It, rather
than the host, adds the PR option and then sends the packet on the
Policy Gateway (or the matching Server in the next AR playing its
part) for relaying.
By controlling how routes are propagated by the regular gateways, it
is possible to prevent hosts from manually setting up routes to
bypass the Servers. In any event, enforcement is not the primary
concern in Phase I of the experiment.
In Phase II, certain of the current gateways are augmented with the
Policy Gateway functions. This will make enforcement easier, and
eliminate the extra hop which the packet had make in Phase I, as it
passed from one Server to another through the current gateway. At
the same time, some of the hosts are modified to insert the IP PR
option into the packet at the source. This will explore the problems
of PR selection.
In Phase III, the PR design is proposed for general implementation.
12. Policy Route Setup
One objection to this scheme is the large size of the IP PR option.
With all the information proposed in this memo, it is larger than the
IP header itself. However, this problem can easily be avoided; the
PR option seldom need be sent.
Since the Policy Gateways are going to cache the result of processing
the PR, the cache holds the equivalent of the PR. All that is
required is a very short option in the packet which is a handle that
permits the gateway to find the correct cache entry. This handle
would be included in the original IP PR option, and then repeated in
every packet. The Policy Server which generated the PR could select
the handle, so it would be unique for each AR. Perhaps the AR id and
a 16 bit UID would be sufficient.
The full PR option needs to be in the packet only if the cached
Information in the gateway is lost. If a gateway crashes or the
route changes, the end point must reconstruct the caches in the
series of gateways that form the route. The end point could
determine that this was necessary either when a gateway reports
explicitly that it does not have an entry corresponding to a handle,
or when the host determines that it is not getting the desired
service.
This sort of action can be thought of as an extension to the idea of
retransmitting. In transport protocols such as TCP, the host keeps
track of the behavior of the network, and if it believes that
something is wrong (e.g., there is a lack of an acknowledgment), it
takes action to restore the desired service. Other examples include
switching to another gateway if the currently active adjacent gateway
seems to be down. Sending the full PR option in the packet is just
another example of allowing the end node to restore the state of the
connection if it seems to be broken.
Using this model, most packets would have only a short option
(perhaps 12 bytes).
This idea of restoring the state in the gateway as needed achieves
the idea of "soft state" mentioned earlier, and allows gateways with
state to achieve the same robustness associated with datagram
networks.
Author's Address
David D. Clark
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Main Street
Cambridge, MA 02139
Phone: (617) 253-6003
Email: ddc@LCS.MIT.EDU