idnits 2.17.1 draft-perkins-irrep-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2015) is 3254 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) == Missing Reference: 'Address' is mentioned on line 201, but not defined == Missing Reference: 'OrigAddr' is mentioned on line 312, but not defined == Missing Reference: 'TargAddr' is mentioned on line 295, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-manet-aodvv2-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodvv2 (ref. 'I-D.ietf-manet-aodvv2') Summary: 1 error (**), 0 flaws (~~), 5 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 May 30, 2015 5 Expires: December 1, 2015 7 Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing 8 draft-perkins-irrep-03 10 Abstract 12 The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is 13 intended for use by mobile routers in wireless, multihop networks. 14 AODVv2 determines unicast routes among AODVv2 routers within the 15 network in an on-demand fashion, offering on-demand convergence in 16 dynamic topologies. This document specifies an extension to AODVv2 17 (possibly useful with other reactive routing protocols) enabling 18 intermediate nodes to shorten route discovery times. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 1, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 56 3. Intermediate RREP Protocol Features . . . . . . . . . . . . . 5 57 4. Intermediate RREP Generation . . . . . . . . . . . . . . . . 6 58 5. Unsolicited RREP Generation . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 63 Appendix A. Changes since version ...-02 . . . . . . . . . . . . 8 64 Appendix B. Previous Changes . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Overview 69 The Ad Hoc On-demand Distance Vector (AODVv2) routing protocol 70 [I-D.ietf-manet-aodvv2] enables on-demand, multihop unicast routing 71 among participating AODVv2 routers. The basic operations of the 72 AODVv2 protocol are route discovery and route maintenance. Route 73 discovery is performed by an AODVv2 router when one of its clients 74 (called OrigNode) attempts to transmit a packet towards a destination 75 for which the router does not have a route. 77 OrigNode's AODVv2 router (denoted RREQ_Gen) initiates route discovery 78 by multicasting a Route Request (RREQ). During the hop-by-hop 79 multicast operation, each intermediate AODVv2 router records a route 80 to the IP address of OrigNode (i.e., OrigAddr). If an intermediate 81 router has a route to the destination requested (denoted TargAddr) in 82 the RREQ, it could transmit an RREP with that routing information to 83 RREQ_Gen. Such an RREP message is called an "Intermediate RREP" (or, 84 "iRREP"). The intermediate router (denoted iRREP_Gen) also generates 85 another RREP message, which is called an "Unsolicited RREP" (or, 86 "uRREP"), to TargRtr, the router TargAddr. The uRREP supplies 87 TargRtr and other intermediate routers with a route towards OrigAddr. 88 When RREQ_Gen receives the iRREP, and TargRtr receives the uRREP, a 89 bi-directional route is established between RREQ_Gen and TargRtr. 91 In this document, RREQ always refers to the incoming RREQ message 92 received by iRREP_Gen. RREQ_Gen, OrigAddr, TargRtr, and TargAddr 93 always refer to the addresses and routers as defined in 94 [I-D.ietf-manet-aodvv2]; they are named from the context of RREQ_Gen 95 (the AODVv2 router originating the RREQ message). 97 Intermediate RREP can be particularly effective in conjunction with 98 the use of "expanding rings multicast", which is specified as an 99 optional feature in [I-D.ietf-manet-aodvv2]. Together, these two 100 features enable a simple "route repair" mechanism. When a route 101 breaks close to the origin, RREQ_Gen MAY limit the flooding of a RREQ 102 using expanding rings multicast. Then, nearby AODVv2 routers could 103 in many situations generate iRREP to supply a new route to the 104 desired destination. 106 When an AODVv2 router receives an RREQ, it first uses the information 107 in the RREQ to update any relevant route table entries. Then, if the 108 router is able to generate an iRREP to satisfy the RREQ, it uses the 109 up-to-date information in its route table to assign proper values to 110 the data elements of the iRREP and uRREP. 112 Other Intermediate routers receiving the iRREP and uRREP messages use 113 the same procedures to process those messages as specified in 114 [I-D.ietf-manet-aodvv2]. In other words, when iRREP_Gen sends iRREP 115 and uRREP messages, other AODVv2 routers along the route receive and 116 regenerate those messages using the same rules as for any other RREP 117 message. 119 2. Terminology and Notation 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. Additionally, this document uses some terminology and 125 notation from [RFC5444] and [I-D.ietf-manet-aodvv2], some of which is 126 duplicated here for convenience. 128 AODVv2 Sequence Number (SeqNum) 129 An AODVv2 Sequence Number is maintained by each AODVv2 router 130 process. This sequence number is used by other AODVv2 routers to 131 identify the temporal order of routing information generated and 132 ensure loop-free routes. 134 Intermediate Route Reply (iRREP) 135 A RREP message that is originated by an Intermediate router. 137 Intermediate Router 138 An AODVv2 router along a route between RREQ_Gen and TargRtr that 139 itself is not RREQ_Gen or TargRtr. 141 iRREP_Gen 142 An Intermediate Router that generates an iRREP message and a uRREP 143 message. 145 OrigAddr 146 An IP address of the Originating Node used as a data element 147 within AODVv2 messages. 149 Originating Node (OrigNode) 150 The Originating Node is the node that launched the application 151 requiring communication with the Target Address. 153 RREQ Generating Router (RREQ_Gen) 154 The AODVv2 router that provides network connectivity to the 155 Originating Node (OrigNode). RREQ_Gen creates a AODVv2 control 156 message (namely, RREQ) on behalf of OrigNode to discover a route 157 to TargAddr. 159 Router Client 160 A node that requires the services of an AODVv2 router for route 161 discovery and maintenance. An AODVv2 router is always its own 162 client, so that its list of client IP addresses is never empty. 164 Target Address (TargAddr) 165 The Target Address is the address for which a route discovery is 166 initiated by RREQ_Gen. 168 Target Router (TargRtr) 169 TargRtr is the AODVv2 router providing connectivity for TargAddr. 171 Unsolicited Route Reply (uRREP) 172 An unsolicited RREP message is a RREP originated by an AODVv2 173 router to a router which did not send a RREQ. In previous 174 documents, uRREP was also sometimes called "Gratuitous RREP". 176 This document uses the Data Elements and conventions found in Table 1 177 and Table 2. 179 +------------------+------------------------------------------------+ 180 | Data Elements | Meaning | 181 +------------------+------------------------------------------------+ 182 | MetricType | The metric type for OrigMetric and TargMetric | 183 | AddressList | A list of IP addresses | 184 | OrigAddr | IP address of the Originating Node | 185 | TargAddr | IP address of the Target Node | 186 | PrefixLengthList | Routing prefixes associated with addresses in | 187 | | AddressList | 188 | OrigSeqNum | Originating Node Sequence Number | 189 | TargSeqNum | Target Node Sequence Number | 190 | OrigMetric | Metric value for route to OrigAddr | 191 | TargMetric | Metric value for route to TargAddr | 192 | ValidityTime | Validity Time values for routes | 193 +------------------+------------------------------------------------+ 195 Table 1 197 +------------------------+------------------------------------------+ 198 | Notation | Meaning | 199 +------------------------+------------------------------------------+ 200 | Route[Address] | A route table entry towards Address | 201 | Route[Address].{field} | A field in such a route table entry | 202 | -- | -- | 203 | iRREP_Gen | AODVv2 Router generating Intermediate | 204 | | RREP | 205 | uOrigAddr | Used as OrigAddr in the uRREP message | 206 | uTargAddr | Used as TargAddr in the uRREP message | 207 +------------------------+------------------------------------------+ 209 Table 2 211 3. Intermediate RREP Protocol Features 213 The protocol features specified in this document are as follows: 215 o DestOnly Message TLV 217 o iRREP 219 o uRREP 221 RREQ_Gen MAY specify that only the router serving TargAddr is allowed 222 to generate an RREP message, by including the DestOnly data element 223 (see Section 6) as part of the message. This also assures that 224 RREP_Gen increments its sequence number. Otherwise Intermediate 225 AODVv2 routers MAY respond to the RREQ if they have a valid route to 226 TargAddr, as detailed in this document. 228 If an intermediate AODVv2 router (iRREP_Gen) has a Route that can 229 satisfy an incoming RREQ, it MAY respond with an Intermediate RREP 230 (iRREP). As usual with any incoming RREQ, iRREP_Gen first updates 231 its route table using the information contained in the RREQ. For 232 example, a route to OrigAddr may be created or updated. After the 233 incoming route update information is applied, iRREP_Gen has valid 234 routes to both OrigAddr and TargAddr (Route[OrigAddr] and 235 Route[TargAddr] respectively). 237 iRREP_Gen SHOULD also send a RREP to TargRtr, so that TargRtr can 238 obtain a route towards OrigAddr. This RREP sent towards the TargAddr 239 is known as an "Unsolicited RREP" (uRREP). Each AODVv2 router 240 between iRREP_Gen and TargRtr that receives the uRREP, uses the uRREP 241 information to update their route table entry for OrigAddr. 243 The following conditions must be satisfied before iRREP_Gen can 244 generate iRREP and uRREP. 246 o RREQ does not contain the DestOnly Message TLV. 248 o iRREP_Gen has a valid route with the same MatricType for TargAddr 249 (namely Route[TargAddr]). 251 o Route[TargAddr].SeqNum >= RREQ.TargSeqNum 253 4. Intermediate RREP Generation 255 The data elements for the iRREP are assigned as follows. 257 o IP.DestinationAddr := Route[OrigAddr].NextHop 259 o AddressList := {OrigAddr, TargAddr} 261 o TargSeqNum := Route[TargAddr].Seqnum 263 o Include the MetricType data element if offering a route for a non- 264 default metric type, and set the type accordingly. 266 o MetricList := {null, Route[TargAddr].Metric} 268 o PrefixLengthList contains the length of the prefix for TargAddr, 269 if TargAddr resides on a Client Network with a prefix length 270 shorter than the number of bits of the address family for 271 TargAddr. 273 o If Route[TargAddr].Timed is TRUE, include the ValidityTimeList and 274 set ValidityTimeList := {Route[TargAddr].ExpirationTime - 275 Current_Time, null} 277 If TargAddr has an associated subnet prefix in the route table, 278 insert its prefix in the PrefixLengthList; otherwise, omit the 279 PrefixLengthList. 281 5. Unsolicited RREP Generation 283 The uRREP is intended to fulfill the function of an RREP as if in 284 response to a (fictional) RREQ message sent by TargRtr for 285 discovering a route to OrigAddr. The sense of the addresses in the 286 uRREP has to be reversed. To reduce confusion which might result 287 from this reversal, the OrigAddr data element of the uRREP is denoted 288 "uOrigAddr"; uOrigAddr has the same value as the TargAddr of the 289 incoming RREQ. Similarly, the TargAddr data element is denoted 290 "uTargAddr", and it has the same value as the OrigAddr of the 291 incoming RREQ. 293 The data elements of the uRREP are assigned as follows. 295 o IP.DestinationAddr := Route[TargAddr].NextHop 297 o AddressList := {uOrigAddr, uTargAddr} 299 o TargSeqNum := Route[uTargAddr].Seqnum 301 o Include the MetricType data element if offering a route for a non- 302 default metric type, and set the type accordingly. 304 o MetricList := {null, Route[uTargAddr].Metric} 306 o PrefixLengthList contains the length of the prefix for uTargAddr, 307 if uTargAddr resides on a Client Network with a prefix length 308 shorter than the number of bits of the address family for 309 uTargAddr. 311 o If Route[OrigAddr].Timed is TRUE, include the ValidityTimeList and 312 set ValidityTimeList := {Route[OrigAddr].ExpirationTime - 313 Current_Time, null}. 315 6. IANA Considerations 317 This section specifies one new RFC 5444 message-tlv type. 319 +------------------------------------+-------+----------+-----------+ 320 | Name of RFC 5444 Message TLV | Type | Length | Cross | 321 | | | (octets) | Reference | 322 +------------------------------------+-------+----------+-----------+ 323 | Destination RREP Only (DestOnly) | TBD | 0 | Section 3 | 324 +------------------------------------+-------+----------+-----------+ 326 Table 3: RFC 5444 Message TLV Types 328 7. Acknowledgments 330 Victoria Mercieca 332 8. Security Considerations 334 Since the RREP message is used in the same way as in AODVv2, no new 335 security vulnerabilities are introduced. The effect of an 336 intermediate node erroneously inserting a DestOnly TLV is minimal, 337 and would simply prevent other routers from offering the benefit of 338 generating Intermediate RREP. Security associations SHOULD be 339 maintained in the same way as specified in AODVv2 340 [I-D.ietf-manet-aodvv2]. Likewise, RREP messages generated according 341 to the specification in this document SHOULD be protected in the same 342 way as specified in AODVv2 [I-D.ietf-manet-aodvv2]. 344 9. Normative References 346 [I-D.ietf-manet-aodvv2] 347 Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 348 V. Mercieca, "Ad Hoc On-demand Distance Vector (AODVv2) 349 Routing", draft-ietf-manet-aodvv2-09 (work in progress), 350 May 2015. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 356 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 357 Format", RFC 5444, February 2009. 359 Appendix A. Changes since version ...-02 361 o Text rewritten to conform to new terminology in 362 [I-D.ietf-manet-aodvv2]. 364 o Updated to handle nondefault metrics. 366 o Replace SeqNum by OrigSeqNum and TargSeqNum as needed. 368 o Minor editorial improvements. 370 Appendix B. Previous Changes 372 o Many changes for RFC 5444 compliance. 374 o Added unsolicitied RREP (uRREP). 376 o Added notation from [I-D.ietf-manet-aodvv2]. 378 o Rewrote many paragraphs to conform to above changes. 380 o Added section about "prefix-length"=0. 382 o Added this "Changes" section. 384 Author's Address 386 Charles E. Perkins 387 Futurewei Inc. 388 2300 Central Expressway 389 Santa Clara, CA 95053 390 USA 392 Phone: +1-408-330-4586 393 Email: charliep@computer.org