idnits 2.17.1 draft-katz-router-alert-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 25, 1996) is 10258 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-11 Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dave Katz 2 Expiration: September 1996 cisco Systems 3 File: draft-katz-router-alert-02.txt March 25, 1996 5 IP Router Alert Option 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Abstract 27 This memo describes a new IP Option type that alerts transit routers 28 to more closely examine the contents of an IP packet. This is useful 29 for, but not limited to, new protocols that are addressed to a 30 destination but require relatively complex processing in routers 31 along the path. 33 1.0 Introduction 35 A recent trend in routing protocols is to loosely couple new routing 36 functionality to existing unicast routing. The motivation for this 37 is simple and elegant -- it allows deployment of new routing 38 functionality without having to reinvent all of the basic routing 39 protocol functions, greatly reducing specification and implementation 40 complexity. 42 The downside of this is that the new functionality can only depend on 43 the least common denominator in unicast routing, the next hop toward 44 the destination. No assumptions can be made about the existence of 45 more richly detailed information (such as a link state database). 47 It is also desirable to be able to gradually deploy the new 48 technology, specifically to avoid having to upgrade all routers in 49 the path between source and destination. This goal is somewhat at 50 odds with the least common denominator information available, since a 51 router that is not immediately adjacent to another router supporting 52 the new protocol has no way of determining the location or identity 53 of other such routers (unless something like a flooding algorithm is 54 implemented over unicast forwarding, which conflicts with the 55 simplicity goal). 57 One obvious approach to leveraging unicast routing is to do hop-by- 58 hop forwarding of the new protocol packets along the path toward the 59 ultimate destination. Each system that implements the new protocol 60 would be responsible for addressing the packet to the next system in 61 the path that understood it. As noted above, however, it is 62 difficult to know the next system implementing the protocol. The 63 simple, degenerate case is to assume that every system along the path 64 implements the protocol. This is a barrier to phased deployment of 65 the new protocol, however. 67 RSVP [1] finesses the problem by instead putting the the address of 68 the ultimate destination in the IP Destination Address field, and 69 then asking that every RSVP router make a "small change in its ... 70 forwarding path" to look for the specific RSVP packet type and pull 71 such packets out of the mainline forwarding path, performing local 72 processing on the packets before forwarding them on. This has the 73 decided advantage of allowing automatic tunneling through routers 74 that don't understand RSVP, since the packets will naturally flow 75 toward the ultimate destination. However, the performance cost of 76 making this Small Change may be unacceptable, since the mainline 77 forwarding path of routers tends to be highly tuned--even the 78 addition of a single instruction may incur penalties of hundreds of 79 PPS in performance. 81 2.0 Router Alert Option 83 The goal, then, is to provide a mechanism whereby routers can 84 intercept packets not addressed to them directly, without incurring 85 any significant performance penalty. This document defines a new IP 86 option type, Router Alert, for this purpose. 88 The Router Alert option has the semantic "routers should examine this 89 packet more closely". By including the Router Alert option in the IP 90 header of its protocol message, RSVP can cause the message to be 91 intercepted while causing little or no performance penalty on the 92 forwarding of normal data packets. 94 Routers that support option processing in the fast path already 95 demultiplex processing based on the option type field. If all option 96 types are supported in the fast path, then the addition of another 97 option type to process is unlikely to impact performance. If some 98 option types are not supported in the fast path, this new option type 99 will be unrecognized and cause packets carrying it to be kicked out 100 into the slow path, so no change to the fast path is necessary, and 101 no performance penalty will be incurred for regular data packets. 103 Routers that do not support option processing in the fast path will 104 cause packets carrying this new option to be forwarded through the 105 slow path, so no change to the fast path is necessary and no 106 performance penalty will be incurred for regular data packets. 108 2.1 Syntax 110 The Router Alert option has the following format: 112 +--------+--------+--------+--------+ 113 |10010100|00000100| 2 octet value | 114 +--------+--------+--------+--------+ 116 Type: 117 Copied flag: 1 (all fragments must carry the option) 118 Option class: 0 (control) 119 Option number: 20 (decimal) 121 Length: 4 123 Value: A two octet code with the following values: 124 0 - Router shall examine packet 125 1-65535 - Reserved 127 2.2 Semantics 129 Hosts shall ignore this option. Routers that do not recognize this 130 option shall ignore it. Routers that recognize this option shall 131 examine packets carrying it more closely (check the IP Protocol 132 field, for example) to determine whether or not further processing is 133 necessary. Unrecognized value fields shall be silently ignored. 135 The semantics of other values in the Value field are for further 136 study. 138 3.0 Impact on Other Protocols 139 For this option to be effective, its use must be mandated in 140 protocols that expect routers to perform significant processing on 141 packets not directly addressed to them. It may also be useful to 142 modify protocols that use the hop-by-hop method to instead use the 143 ultimate destination as the IP Destination Address and then mandate 144 the use of this option. 146 4.0 References 148 [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, 149 "Resource ReSerVation Protocol (RSVP)," draft-ietf-rsvp-spec- 150 11.txt, March 1996. 152 Author's Address 154 Dave Katz 155 cisco Systems 156 170 W. Tasman Dr. 157 San Jose, CA 95134-1706 USA 159 Phone: +1 408 526 8284 160 Email: dkatz@cisco.com