idnits 2.17.1 draft-perkins-manet-precursor-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2012) is 4301 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) == Unused Reference: 'RFC3561' is defined on line 208, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-22 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track July 14, 2012 5 Expires: January 15, 2013 7 Precursor Notification for dynamic MANET On-demand (AODVv2) Routing 8 draft-perkins-manet-precursor-01 10 Abstract 12 The Dynamic MANET On-demand (AODVv2) routing protocol is intended for 13 use by mobile routers in wireless, multihop networks. AODVv2 14 determines unicast routes among AODVv2 routers within the network in 15 an on-demand fashion, offering on-demand convergence in dynamic 16 topologies. This document specifies a simple modification to AODVv2 17 (and possibly other reactive routing protocols) enabling faster 18 notifications to known sources of traffic upon determination that a 19 route for such traffic's destination has become invalid. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 15, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Precursor Notification . . . . . . . . . . . . . . . . . . . . 4 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Overview 67 If an AODVv2 router, while attempting to forward a packet to a 68 particular destination, determines that the next hop (one of its 69 neighbors) is no longer reachable, AODVv2 specifies that the router 70 notify the source of that packet that the route to the destination 71 has become invalid. In the existing specification, the notification 72 to the source is a unicast RERR message. 74 However, in many cases there will be several sources of of traffic 75 for that particular destination. In fact, the broken link for the 76 next hop in question may be a path component of numerous other routes 77 for other destinations, and in that case the node detecting the 78 broken link must invalidate multiple routes, one for each of the 79 newly unreachable destinations. Each route that uses the newly 80 broken link is no longer valid. For each such route, every node 81 along the way from the source using that route, to the node detecting 82 the broken link, is known as a "precursor" for the broken next hop. 83 All the precursors for a particular next hop should be notified about 84 the change in status of their route to a destination downstream from 85 the broken next hop. This can be done in several ways. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 92 Additionally, this document uses some terminology from [RFC5444] and 93 [I-D.ietf-manet-dymo], duplicated here for convenience. 95 AODVv2 Sequence Number (SeqNum) 96 An AODVv2 Sequence Number is maintained by each AODVv2 router 97 process. This sequence number is used by other AODVv2 routers to 98 identify the temporal order of routing information generated and 99 ensure loop-free routes. 101 Originating Node (OrigNode) 102 The originating node is the source, its AODVv2 router creates a 103 AODVv2 control message on its behalf in an effort to disseminate 104 some routing information. The originating node is also referred 105 to as a particular message's originator. 107 Route Reply (RREP) 108 A RREP message is used to disseminate routing information about 109 the RREP TargetNode to the RREP OrigNode and the AODVv2 routers 110 between them. 112 Route Request (RREQ) 113 A RREQ message is used to discover a valid route to a particular 114 destination address, called the RREQ TargetNode. When an AODVv2 115 router processes a RREQ, it learns routing information on how to 116 reach the RREQ OrigNode. 118 Target Node (TargetNode) 119 The TargetNode is the ultimate destination of a message. 121 This Node (ThisNode) 122 ThisNode corresponds to the AODVv2 router process currently 123 performing a calculation or attending to a message. 125 3. Precursor Notification 127 During normal operation, each node wishing to enable the improved 128 notification for precursors of any links to its next hop neighbors 129 has to keep track of the precursors. This is done by maintaining a 130 precursor table and updating the table whenever the node initiates or 131 relays a RREP message back to a node originating a RREQ message. 132 When the node transmits the RREP message, it is implicitly agreeing 133 to forward traffic from the RREQ originator towards the RREP 134 originator (i.e., along the next hop link to the neighbor from which 135 the RREP was received). The "other" next hop, which is the neighbor 136 along the way towards the originator of the RREQ message, is then the 137 next precursor for the route towards the destination requested by the 138 RREQ. 140 Each such precursor should then be recorded as a precursor for a 141 route along the next hop. The same next hop may be in service for 142 routes to multiple destinations, but for precursor list management it 143 is only important to keep track of precursors for a particular next 144 hop; the exact destination does not matter, only the particular next 145 hop towards the destination(s). 147 When a node observes that one of its neighbors is no longer 148 reachable, the node first checks to see whether the link to that 149 neighbor is a next hop for any more distant destination in its route 150 table. If not, then the node simply updates any relevant neighorhood 151 information and takes no further action. 153 Otherwise, for all destinations no longer reachable because of the 154 changed status of the next hop, the node first checks to see whether 155 the link to that neighbor is a next hop for any more distant 156 destination in its route table. If not, then the node simply updates 157 any relevant neighorhood information and takes no further action. 159 For each precursor of the next hop, the node MAY notify the precursor 160 in one of three ways: 162 o unicast RERR 164 o broadcast RERR 166 o multicast RERR to multicast group PRECURSOR_RERR_RECEIVERS 168 Each precursor then MAY execute the same procedure until all affected 169 traffic sources have received the RERR route maintenance information. 171 When a precursor receives a unicast RERR, the precursor MUST further 172 unicast the RERR message towards the affected traffic source. If a 173 precursor receives a broadcast or multicast RERR, the precursor MAY 174 further retransmit the RERR towards the traffic source. 176 4. Acknowledgments 178 TBD 180 5. Security Considerations 182 The ability of to use broadcast instead of unicast can in some cases 183 cause additional network traffic. This would happen when many 184 traffic sources were never going to re-use a particular route, and 185 yet were receiving essentially useless notifications about that 186 route. It remains to be determined whether such scenarios, where 187 route tables have significant numbers of useless routes, would be 188 encountered in practice. 190 6. References 192 6.1. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 198 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 199 Format", RFC 5444, February 2009. 201 6.2. Informative References 203 [I-D.ietf-manet-dymo] 204 Perkins, C. and I. Chakeres, "Dynamic MANET On-demand 205 (AODVv2) Routing", draft-ietf-manet-dymo-22 (work in 206 progress), March 2012. 208 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 209 Demand Distance Vector (AODV) Routing", RFC 3561, 210 July 2003. 212 Author's Address 214 Charles E. Perkins 215 Futurewei Inc. 216 2330 Central Expressway 217 Santa Clara, CA 95050 218 USA 220 Phone: +1-408-421-1172 221 Email: charliep@computer.org