RFC 2113 (rfc2113) - Page 2 of 4

IP Router Alert Option

RFC 2113                  Router Alert Option              February 1997


   One obvious approach to leveraging unicast routing is to do hop-by-
   hop forwarding of the new protocol packets along the path toward the
   ultimate destination.  Each system that implements the new protocol
   would be responsible for addressing the packet to the next system in
   the path that understood it.  As noted above, however, it is
   difficult to know the next system implementing the protocol.  The
   simple, degenerate case is to assume that every system along the path
   implements the protocol.  This is a barrier to phased deployment of
   the new protocol, however.

   RSVP [1] finesses the problem by instead putting the address of the
   ultimate destination in the IP Destination Address field, and then
   asking that every RSVP router make a "small change in its ...
   forwarding path" to look for the specific RSVP packet type and pull
   such packets out of the mainline forwarding path, performing local
   processing on the packets before forwarding them on.  This has the
   decided advantage of allowing automatic tunneling through routers
   that don't understand RSVP, since the packets will naturally flow
   toward the ultimate destination.  However, the performance cost of
   making this Small Change may be unacceptable, since the mainline
   forwarding path of routers tends to be highly tuned--even the
   addition of a single instruction may incur penalties of hundreds of
   packets per second in performance.

2.0  Router Alert Option

   The goal, then, is to provide a mechanism whereby routers can
   intercept packets not addressed to them directly, without incurring
   any significant performance penalty.  This document defines a new IP
   option type, Router Alert, for this purpose.

   The Router Alert option has the semantic "routers should examine this
   packet more closely".  By including the Router Alert option in the IP
   header of its protocol message, RSVP can cause the message to be
   intercepted while causing little or no performance penalty on the
   forwarding of normal data packets.

   Routers that support option processing in the fast path already
   demultiplex processing based on the option type field.  If all option
   types are supported in the fast path, then the addition of another
   option type to process is unlikely to impact performance.  If some
   option types are not supported in the fast path, this new option type
   will be unrecognized and cause packets carrying it to be kicked out
   into the slow path, so no change to the fast path is necessary, and
   no performance penalty will be incurred for regular data packets.






Katz                        Standards Track