idnits 2.17.1 draft-ahn-manet-dsr-crri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 14, 2016) is 2691 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 70 == Missing Reference: '2' is mentioned on line 130, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 4728 (ref. '1') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MANET Working Group Sanghyun Ahn 2 Internet Draft University of Seoul 3 Expires: May 6, 2017 November 14, 2016 5 DSR Extensions for the Resolution of Cached Route Reply Implosion 6 draft-ahn-manet-dsr-crri-01.txt 8 Status of this Memo 10 This Internet-Draft is submitted to IETF in full conformance with the 11 provisions of BCP 78 and BCP 79. This document may not be modified, 12 and derivative works of it may not be created, except to format it 13 for publication as an RFC or to translate it into languages other 14 than English. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 6, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 In DSR, a node can generate a route reply in response to a received 48 route request if it has a fresh route to the destination in its 49 route cache. However, this can incur the cached route reply problem 50 and DSR just tries to mitigate this problem by reducing the 51 possibility of cached route reply collisions. This document 52 describes how DSR can be extended for the resolution of the cached 53 route reply problem. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Extensions on DSR Route Request Option . . . . . . . . . . . . 3 60 4. Operations Related to C Flag . . . . . . . . . . . . . . . . . 5 61 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 The DSR protocol [1] works based on the source routing mechanism 74 and support multiple routes between a source and destination node 75 pair by maintaining several routes in the route cache at the source. 76 However, in DSR, the route reply storm problem can happen 77 because of route replies generated by intermediate nodes with fresh 78 routes to the destination in their own route caches (i.e., cached 79 route replies). DSR tries to solve this route reply storm problem 80 by reducing the possibility of route reply collisions with adding 81 a short jitter delay before the broadcast of a route reply. 82 However, DSR does not try to resolve the cause of the route reply 83 storm problem. 85 The main reason of the route reply storm is uncontrolled 86 generation of route replies at intermediate nodes, i.e., cached 87 route replies. Therefore, a mechanism to control the generation of 88 route replies at intermediate nodes is required for the effective 89 operation of DSR. However,for the support of multipath routing, 90 too tight restriction (control) on route reply generation may not be 91 desirable. Therefore, when controlling the generation of route 92 replies, both of these aspects need to be considered. In this draft, 93 we describe how DSR Options header has to be extended to support 94 the control of generation route replies. 96 3. Extensions on DSR Route Request Option 98 In DSR, there is no way to control the generation of cached route 99 replies, so a C (Cached route reply) bit is inserted in the DSR 100 Route Request option, To do that, the size of the Identification 101 field is reduced to 14 bits from 16 bits. 103 The Route Request option in the DSR Options header is extended as 104 follows: 106 0 1 2 3 107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Option Type | Opt Data Len | Identification |C| Resv| 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Target Address | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Address[1] | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Address[2] | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | ... | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Address[n] | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 IP fields 123 The same as described in [2]. 125 Route Request fields 126 The same as described in [2] except for the Identification field, 127 the C bit and the Resv field. 129 Identification 130 The definition of this field is the same as that in [2]. 131 Only the size of this field is reduced to 12 bits. 133 C 134 C bit is used to indicate whether cached route replies are 135 allowed or not. C bit is set to 1 if the cached route reply 136 is allowed. The intermediate nodes can generate cached route 137 replies only when the C bit of the received Route Request option 138 is 1. Otherwise, only the destination node can generate 139 route replies. 141 Resv 142 The reserved field for further extensions on DSR Route Request 143 option. 145 4. Operations Related to C Flag 147 If a source node has to find a route to a destination, it first 148 checks the ratio of the CRREP messages to the RREP messages 149 received during previous route requests which can be computed by 150 using the exponential weight moving average (EWMA). If the ratio is 151 above the given threshold, it broadcasts an RREQ message with C = 0 152 to discover a route to the destination with the adaptive CRREP 153 generation capability. 155 If a node, which is not the destination, receives an RREQ message 156 with C = 0 and has the route information to the destination 157 specified in the RREQ message, it decides the generation of a 158 CRREP message probabilistically. 160 5. Other Considerations 162 TBD. 164 References 166 [1] D. Johnson, Y. Hu and D. Maltz, "The Dynamic Source Routing 167 Protocol," RFC 4728, February 2007. 169 Author's Address 171 Sanghyun Ahn 172 University of Seoul 173 90, Cheonnong-dong, Tongdaemun-gu 174 Seoul 130-743 175 Korea 176 Email: ahn@uos.ac.kr