Dave Katz INTERNET-DRAFT cisco Systems <draft-katz-router-alert-01.txt> November 16, 1995 IP Router Alert Option Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Abstract This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path. This document specifies an experimental protocol for use in the Internet. 1.0 Introduction A recent trend in routing protocols is to loosely couple new routing functionality to existing unicast routing. The motivation for this is simple and elegant--it allows deployment of new routing functionality without having to reinvent all of the basic routing protocol functions, greatly reducing specification and implementation complexity. The downside of this is that the new functionality can only depend on Katz Expires May 16, 1996 [Page 1]
INTERNET-DRAFT Router Alert Option November 16, 1995 the least common denominator in unicast routing--the next hop toward the destination. No assumptions can be made about the existence of more richly detailed information (such as a link state database). It is also desirable to be able to gradually deploy the new technology, specifically to avoid having to upgrade all routers in the path between source and destination. This goal is somewhat at odds with the least common denominator information available, since a router that is not immediately adjacent to another router supporting the new protocol has no way of determining the location or identity of other such routers (unless something like a flooding algorithm is implemented over unicast forwarding, which conflicts with the simplicity goal). 2.0 Approaches to Coupling with Routing 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 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 PPS in performance. 3.0 Proposal The goal, then, is to provide a mechanism whereby routers can intercept packets not addressed to them directly without incurring any significant performance penalty. The proposed solution is to define a new IP option type with the semantic "routers should examine Katz Expires May 16, 1996 [Page 2]
INTERNET-DRAFT Router Alert Option November 16, 1995 this packet more closely" and require protocols such as RSVP to use this option. This would incur 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. Routers that do not support option processing in the fast path will cause packets carrying this new option to be forwarded through the slow path, so no change to the fast path is necessary and no performance penalty will be incurred for regular data packets. 3.1 Syntax The proposed 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 packet 1-65535 - Reserved 3.2 Semantics Hosts shall ignore this option. Routers that do not recognize this option shall ignore it. Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary. Unrecognized value fields shall be silently ignored. Katz Expires May 16, 1996 [Page 3]
INTERNET-DRAFT Router Alert Option November 16, 1995 The semantics of other values in the Value field are for further study. 4.0 Impact on Other Protocols For this option to be effective, its use must be mandated in protocols that expect routers to perform significant processing on packets not directly addressed to them. It may also be useful to modify protocols that use the hop-by-hop method to instead use the ultimate destination as the IP Destination Address and then mandate the use of this option. 5.0 References [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)," draft-ietf-rsvp-spec- 07.txt, 1995. Author's Address Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA Phone: +1 408 526 8284 Email: dkatz@cisco.com Katz Expires May 16, 1996 [Page 4]