As per Relevance of the word processing, we have this rfc below:
Network Working Group D.
Request for Comments: 2113 cisco
Category: Standards Track February 1997
IP Router Alert
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo describes a new IP Option type that alerts transit
to more closely examine the contents of an IP packet. This is
for, but not limited to, new protocols that are addressed to
destination but require relatively complex processing in
along the path
1.0
A recent trend in routing protocols is to loosely couple new
functionality to existing unicast routing. The motivation for
is simple and elegant -- it allows deployment of new
functionality without having to reinvent all of the basic
protocol functions, greatly reducing specification and
complexity
The downside of this is that the new functionality can only depend
the least common denominator in unicast routing, the next hop
the destination. No assumptions can be made about the existence
more richly detailed information (such as a link state database).
It is also desirable to be able to gradually deploy the
technology, specifically to avoid having to upgrade all routers
the path between source and destination. This goal is somewhat
odds with the least common denominator information available, since
router that is not immediately adjacent to another router
the new protocol has no way of determining the location or
of other such routers (unless something like a flooding algorithm
implemented over unicast forwarding, which conflicts with
simplicity goal).
Katz Standards Track [Page 1]
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
ultimate destination. Each system that implements the new
would be responsible for addressing the packet to the next system
the path that understood it. As noted above, however, it
difficult to know the next system implementing the protocol.
simple, degenerate case is to assume that every system along the
implements the protocol. This is a barrier to phased deployment
the new protocol, however
RSVP [1] finesses the problem by instead putting the address of
ultimate destination in the IP Destination Address field, and
asking that every RSVP router make a "small change in its ...
forwarding path" to look for the specific RSVP packet type and
such packets out of the mainline forwarding path, performing
processing on the packets before forwarding them on. This has
decided advantage of allowing automatic tunneling through
that don't understand RSVP, since the packets will naturally
toward the ultimate destination. However, the performance cost
making this Small Change may be unacceptable, since the
forwarding path of routers tends to be highly tuned--even
addition of a single instruction may incur penalties of hundreds
packets per second in performance
2.0 Router Alert
The goal, then, is to provide a mechanism whereby routers
intercept packets not addressed to them directly, without
any significant performance penalty. This document defines a new
option type, Router Alert, for this purpose
The Router Alert option has the semantic "routers should examine
packet more closely". By including the Router Alert option in the
header of its protocol message, RSVP can cause the message to
intercepted while causing little or no performance penalty on
forwarding of normal data packets
Routers that support option processing in the fast path
demultiplex processing based on the option type field. If all
types are supported in the fast path, then the addition of
option type to process is unlikely to impact performance. If
option types are not supported in the fast path, this new option
will be unrecognized and cause packets carrying it to be kicked
into the slow path, so no change to the fast path is necessary,
no performance penalty will be incurred for regular data packets
Katz Standards Track [Page 2]
RFC 2113 Router Alert Option February 1997
Routers that do not support option processing in the fast path
cause packets carrying this new option to be forwarded through
slow path, so no change to the fast path is necessary and
performance penalty will be incurred for regular data packets
2.1
The Router Alert option has the following format
+--------+--------+--------+--------+
|10010100|00000100| 2 octet value |
+--------+--------+--------+--------+
Type
Copied flag: 1 (all fragments must carry the option
Option class: 0 (control
Option number: 20 (decimal
Length: 4
Value: A two octet code with the following values
0 - Router shall examine
1-65535 -
2.2
Hosts shall ignore this option. Routers that do not recognize
option shall ignore it. Routers that recognize this option
examine packets carrying it more closely (check the IP
field, for example) to determine whether or not further processing
necessary. Unrecognized value fields shall be silently ignored
The semantics of other values in the Value field are for
study
3.0 Impact on Other
For this option to be effective, its use must be mandated
protocols that expect routers to perform significant processing
packets not directly addressed to them. Currently such
include RSVP [1] and IGMP [2].
4.0 Security
If the Router Alert option is not set and should be set, the
of the protocol using the Router Alert, e.g., RSVP or IGMPv2, will
adversely affected since the protocol relies on the use of the
Alert option
Katz Standards Track [Page 3]
RFC 2113 Router Alert Option February 1997
If the Router Alert option is set when it should not be set, it
likely that the flow will experience a performance penalty, as
packet whose Router Alert option is set will not go through
router's fastpath and will be processed in the router more
than if the option were not set
5.0
[1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin
"Resource ReSerVation Protocol (RSVP)," work in progress,
1996.
[2] Fenner, W., "Internet Group Management Protocol, Version 2
(IGMPv2)," work in progress, October 1996.
Author's
Dave
cisco
170 W. Tasman Dr
San Jose, CA 95134-1706
Phone: +1 408 526 8284
Email: dkatz@cisco.
Katz Standards Track [Page 4]
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
