idnits 2.17.1 draft-katz-router-alert-01.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. ** 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 (November 16, 1995) is 10388 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-07 Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dave Katz 2 INTERNET-DRAFT cisco Systems 3 November 16, 1995 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 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the I-D abstract listing contained in each Internet 21 Draft directory to learn the current status of this or any Internet 22 Draft. 24 Abstract 26 This memo describes a new IP Option type that alerts transit routers 27 to more closely examine the contents of an IP packet. This is useful 28 for, but not limited to, new protocols that are addressed to a 29 destination but require relatively complex processing in routers 30 along the path. 32 This document specifies an experimental protocol for use in the 33 Internet. 35 1.0 Introduction 37 A recent trend in routing protocols is to loosely couple new routing 38 functionality to existing unicast routing. The motivation for this 39 is simple and elegant--it allows deployment of new routing 40 functionality without having to reinvent all of the basic routing 41 protocol functions, greatly reducing specification and implementation 42 complexity. 44 The downside of this is that the new functionality can only depend on 45 the least common denominator in unicast routing--the next hop toward 46 the destination. No assumptions can be made about the existence of 47 more richly detailed information (such as a link state database). 49 It is also desirable to be able to gradually deploy the new 50 technology, specifically to avoid having to upgrade all routers in 51 the path between source and destination. This goal is somewhat at 52 odds with the least common denominator information available, since a 53 router that is not immediately adjacent to another router supporting 54 the new protocol has no way of determining the location or identity 55 of other such routers (unless something like a flooding algorithm is 56 implemented over unicast forwarding, which conflicts with the 57 simplicity goal). 59 2.0 Approaches to Coupling with Routing 61 One obvious approach to leveraging unicast routing is to do hop-by- 62 hop forwarding of the new protocol packets along the path toward the 63 ultimate destination. Each system that implements the new protocol 64 would be responsible for addressing the packet to the next system in 65 the path that understood it. As noted above, however, it is 66 difficult to know the next system implementing the protocol. The 67 simple, degenerate case is to assume that every system along the path 68 implements the protocol. This is a barrier to phased deployment of 69 the new protocol, however. 71 RSVP [1] finesses the problem by instead putting the the address of 72 the ultimate destination in the IP Destination Address field, and 73 then asking that every RSVP router make a "small change in 74 its...forwarding path" to look for the specific RSVP packet type and 75 pull such packets out of the mainline forwarding path, performing 76 local processing on the packets before forwarding them on. This has 77 the decided advantage of allowing automatic tunneling through routers 78 that don't understand RSVP, since the packets will naturally flow 79 toward the ultimate destination. However, the performance cost of 80 making this Small Change may be unacceptable, since the mainline 81 forwarding path of routers tends to be highly tuned--even the 82 addition of a single instruction may incur penalties of hundreds of 83 PPS in performance. 85 3.0 Proposal 87 The goal, then, is to provide a mechanism whereby routers can 88 intercept packets not addressed to them directly without incurring 89 any significant performance penalty. The proposed solution is to 90 define a new IP option type with the semantic "routers should examine 91 this packet more closely" and require protocols such as RSVP to use 92 this option. This would incur little or no performance penalty on 93 the forwarding of normal data packets. 95 Routers that support option processing in the fast path already 96 demultiplex processing based on the option type field. If all option 97 types are supported in the fast path, then the addition of another 98 option type to process is unlikely to impact performance. If some 99 option types are not supported in the fast path, this new option type 100 will be unrecognized and cause packets carrying it to be kicked out 101 into the slow path, so no change to the fast path is necessary, and 102 no performance penalty will be incurred for regular data packets. 104 Routers that do not support option processing in the fast path will 105 cause packets carrying this new option to be forwarded through the 106 slow path, so no change to the fast path is necessary and no 107 performance penalty will be incurred for regular data packets. 109 3.1 Syntax 111 The proposed option has the following format: 113 +--------+--------+--------+--------+ 114 |10010100|00000100| 2 octet value | 115 +--------+--------+--------+--------+ 117 Type: 118 Copied flag: 1 (all fragments must carry the option) 119 Option class: 0 (control) 120 Option number: 20 (decimal) 122 Length: 4 124 Value: A two octet code with the following values: 125 0 - Router shall examine packet 126 1-65535 - Reserved 128 3.2 Semantics 130 Hosts shall ignore this option. Routers that do not recognize this 131 option shall ignore it. Routers that recognize this option shall 132 examine packets carrying it more closely (check the IP Protocol 133 field, for example) to determine whether or not further processing is 134 necessary. Unrecognized value fields shall be silently ignored. 136 The semantics of other values in the Value field are for further 137 study. 139 4.0 Impact on Other Protocols 141 For this option to be effective, its use must be mandated in 142 protocols that expect routers to perform significant processing on 143 packets not directly addressed to them. It may also be useful to 144 modify protocols that use the hop-by-hop method to instead use the 145 ultimate destination as the IP Destination Address and then mandate 146 the use of this option. 148 5.0 References 150 [1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, 151 "Resource ReSerVation Protocol (RSVP)," draft-ietf-rsvp-spec- 152 07.txt, 1995. 154 Author's Address 156 Dave Katz 157 cisco Systems 158 170 W. Tasman Dr. 159 San Jose, CA 95134-1706 USA 161 Phone: +1 408 526 8284 162 Email: dkatz@cisco.com