idnits 2.17.1 draft-ladas-manet-m-cml-00.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ladas-manet-m-cml-01', but the file name used is 'draft-ladas-manet-m-cml-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' The IANA consideration section is required as recommended by [11]' ) ** The abstract seems to contain references ([15], [2], [1-2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 482 has weird spacing: '...pies of the s...' -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '3' on line 774 looks like a reference -- Missing reference section? '6' on line 785 looks like a reference -- Missing reference section? '4' on line 777 looks like a reference -- Missing reference section? '1' on line 768 looks like a reference -- Missing reference section? '8' on line 793 looks like a reference -- Missing reference section? '12' on line 810 looks like a reference -- Missing reference section? '9' on line 797 looks like a reference -- Missing reference section? '1-2' on line 380 looks like a reference -- Missing reference section? '7' on line 789 looks like a reference -- Missing reference section? '2' on line 771 looks like a reference -- Missing reference section? '10' on line 803 looks like a reference -- Missing reference section? '15' on line 819 looks like a reference -- Missing reference section? '11' on line 807 looks like a reference -- Missing reference section? '13' on line 813 looks like a reference -- Missing reference section? '5' on line 781 looks like a reference -- Missing reference section? '14' on line 816 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Ladas 2 Internet Draft D. G C 3 Intended status: Experimental N. Weerasinghe 4 Expires: April 21,2019 C. Politis 5 WMN Research Group 6 Kingston University London, UK 7 October 22, 2018 9 Multipath ChaMeLeon (M-CML): A multipath hybrid routing protocol for 10 MANETs 11 draft-ladas-manet-m-cml-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 21,2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document describes the multipath ChaMeLeon (M-CML) routing 54 protocol designed for Mobile Ad hoc Networks (MANETs). M-CML is a 55 multi-path, hybrid routing protocol operating within a defined area 56 denoted as the Critical Area (CA) in which the MANET is temporarily 57 deployed during the post-disaster phase. The main concept behind M- 58 CML is the adaptability of its routing mechanisms towards changes in 59 the physical and logical state of a MANET. For autonomous 60 communications in MANET, it is likely that the network size varies 61 whenever additional devices join or subset of them leave the 62 network. In addition, battery depletion of lightweight mobile 63 communication devices will stipulate another reason for changes in 64 the network size. As a result, the M-CML approach adapts its routing 65 mechanism according to changes in the network scenario within a 66 predefined CA. For small networks, M-CML routes data proactively 67 using the Optimized Link State Routing version v2 (OLSRv2) protocol 68 whereas for larger networks it utilizes the reactive Ad hoc On- 69 Demand Distance Vector Version 2 (AODVv2) Routing protocol. The 70 oscillation phase is the intermediate phase in which the transition 71 of routing protocol occurs. M-CML creates multi-path routes for 72 nodes with disjoint paths which increases the network reliability. 74 Table of Contents 76 1. Introduction...................................................3 77 2. Conventions used in this document..............................3 78 2.1. M-CML terminology used in this document...................3 79 3. Applicability..................................................4 80 4. Protocol Overview..............................................4 81 4.1. Proactive Routing.........................................4 82 4.2. Monitoring and Analysis...................................5 83 4.3. Adaptive Component........................................6 84 4.4. Oscillation Phase.........................................7 85 5. Protocol Operation.............................................8 86 5.1. M-Phase...................................................8 87 5.2. P-Phase...................................................8 88 5.3. R-Phase...................................................9 89 5.4. O-Phase...................................................9 90 5.5. Algorithm for M-CML ......................................9 91 5.5.1. Protocol Operation..................................10 92 6. M-CML Packet and Message Formats..............................11 93 6.1. Packet Format............................................11 94 6.2. Change Phase (CP) Message................................11 95 6.3. Hop Count Request (HCReq) Message........................11 96 6.4. Hop Count Response (HCRep) Message.......................12 97 7. M-CML tables..................................................12 98 7.1. M-CML Change Phase table.................................12 99 8. M-CML Timers..................................................12 100 8.1. Oscillation timer........................................12 101 9. Constants.....................................................13 102 9.1. Network Threshold Values.................................13 103 9.2. Oscillation Interval (Osc_Interval)......................13 104 9.3. Parameter Values.........................................14 105 10. Message Emission and Jitter..................................14 106 11. IPv6 Considerations..........................................14 107 12. Security Considerations......................................14 108 13. IANA Considerations..........................................15 109 14. Conclusions..................................................15 110 15. References...................................................15 111 15.1. Normative References....................................15 112 15.2. Informative References..................................16 113 16. Acknowledgments..............................................16 115 1. Introduction 117 The protocol discussed in this document is a multipath hybrid 118 routing protocol for MANETs. It consists of four phases of 119 operation, which are considered to be Monitoring, Proactive, 120 Oscillation and Reactive phases. The Proactive Phase, i.e., p-phase 121 and Reactive Phase, i.e., the r-phase operates in the same way as 122 the core functions of [3] and [6], respectively, and are discrete 123 from each other. This draft focuses on the optimization of the p- 124 phase by proposing a new route computation approach compared with 125 [4] for multipath operation. By applying this multipath approach, 126 our main aim is to ensure load balancing, improve QoS and delay, 127 provide reliable communication among the nodes and maximize network 128 life. In this draft, the r-phase of M-CML is not multipath, it is 129 simply an on-demand route computation. M-CML makes no assumptions 130 about the underlying link layer. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC-2119 [1]. 138 2.1. M-CML terminology used in this document 140 This section defines terminology associated with M-CML that is not 141 already defined in or that differs from the meaning of the 142 terminology in [3],[6],[8] and [12]. 144 o The p-phase is based on MP-OLSRv2 Routing Protocols. The routing 145 process is based on the specification [4],[6]. 147 o The m-phase is the monitoring state of the routing node in which 148 it monitors various network parameters, for example, network 149 density, traffic pattern, energy consumption etc., based on which 150 next routing phase is determined. 152 o Proactive Route Computation Terminology - The route computation 153 process that is going to be used in M-CML is based on an Advanced 154 Relay Routing (ARR) approach. 156 o The r-phase remains the same as defined in AODVv2 [3]. 158 3. Applicability 160 The design of M-CML has been constructed to provide robust and 161 efficient communication for wireless networks, by exploiting the 162 multi-path information transfer and optimal combination of the two 163 routing approaches. The autonomous nature of MANETs is very suitable 164 for a variety of scenarios, especially when multiple disjoint paths 165 exist within the CA . Also, in such a context, the number of MANET 166 nodes varies depending on different parameters. 168 o Battery power constraint of mobile nodes is a very important 169 consideration. Node failure as a consequence of battery depletion 170 MAY result in network segmentation. 172 o Nodes MAY join or leave the network at anytime and at any random 173 location. 175 o A certain quality of service (QoS) level has to be maintained to 176 allow for multimedia communication. Mainly, certain delay bounds 177 have to be established while also maintaining effective routing 178 by minimizing battery consumption. 180 M-CML has the ability to adapt its routing behavior on-the-fly 181 according to the changes in MANET size. Therefore, it is a more 182 suitable routing alternative than individual routing approaches for 183 small, large as well as variable sized MANETs operating in a defined 184 CA. Moreover, the M-CML also adapts within the high level of node 185 mobility, which makes it applicable in the very dynamic network 186 topology. 188 4. Protocol Overview 190 This protocol is designed to work as a multi-path, hybrid and 191 adaptive routing protocol for MANETs. The normal mode of operation 192 is under one of the stable phases. The default operating phase is 193 the p-phase. This section describes the various processes and 194 structures introduced by M-CML. 196 4.1. Proactive Routing 198 As soon as the MANET is implemented in the CA, a default routing 199 mode in M-CML is the p-phase, irrespective of the network scenario. 201 4.2. Monitoring and Analysis 203 The monitoring phase (m-phase) is triggered soon after the p-phase 204 starts in section 4.1., i.e., it runs simultaneously with the p- 205 phase. The m-phase is initiated when a control message is received 206 by the monitoring module in the routing node [9]. However, m-phase 207 is triggered in regular intervals even when M-CML runs either in p- 208 phase or r-phase (but it is disabled in o-phase). The node MUST 209 perform the following tasks. 211 1. Send a copy of the packet to the monitor part of the module. The 212 monitoring component has a network size part that MUST check the 213 number of nodes in the network. This is accomplished differently 214 depending on the current stable phase of operation (as described 215 later). 217 2. Send the packet to the regular control message processing by the 218 stable phase, as described in [3] or section 5.2, which is the 219 current active routing part. 221 In the m-phase, the network size is estimated as follows. The m- 222 phase and the p-phase (where the OLSRv2 routing algorithm is active) 223 run concurrently, this task consists of calculating the number of 224 reachable hosts from the routing table as defined in [6]. This 225 calculation is done by counting the number of rows in the proactive 226 routing table. Each row includes fields of possible destination 227 nodes, the next hop to reach the destination as specified in the 228 possible destination field and its distance from the current source 229 node. These field values are computed using periodical Topology 230 Control (TC) and HELLO message broadcasts by each node in the 231 network. If the number of nodes is found to exceed the NST, this 232 monitor part must contact the L-NST part of the Adaptive Component. 234 In the r-phase (where the AODVv2 routing algorithm is active), the 235 number of nodes in the network is estimated using the maximum value 236 of the hop count from a source node to a destination. As defined in 237 [3], a source finds a route to a destination 'on-demand' by flooding 238 a Route Request (RReq) packet throughout the network using an 239 expanding ring approach until a RRep is received from the 240 destination. 242 The monitor function in the source node must use this RRep message 243 to obtain the value of Hop Count (HC) towards the destination node. 244 It then compares this with the U-NST, which is calculated according 245 to the relationship defined in section 9.1. The monitor function 246 MUST act as follows: 248 1. If HC in RRep is greater or equal to U-NST, it decides that the 249 NST is not exceeded. 251 2. If HC in RRep is less than the U-NST, the data packets are 252 transmitted through the established route. After data 253 transmission, the CMLv2 Hop Count Request (HCReq) packet described 254 in section 6.3. MUST be generated and flooded in the network to 255 probe for the network HC (as opposed to destination HC). The HC is 256 said to be less than the NHT, if after 257 RREQ_WAIT_TIME*DISCOVERY_ATTEMPTS_MAX, no HCRep has been received. 258 If the HC is less than the U-NST, the monitor function decides 259 that the r-phase NST (calculated using the relationship in section 260 9.1.), has been exceeded and calls the U-NST part of the Adaptive 261 component. 263 If a node receives HCReq, it must first make sure that the 264 sequence number of the packet is greater than that stored in the 265 Change Phase (CP) table for the same originator address. Then, it 266 checks if the TTL = 0. If the latter is true, it MUST store HCReq 267 originator IP and packet sequence number information in the CP 268 table and send back an HCRep to the originator, as described in 269 section 6.4. Otherwise, it decreases the TTL value and floods back 270 the HCReq packet in the network. It then generates and floods its 271 own HCReq to probe for the HC with TTL value set to NHT. The value 272 of the originator address of the original HCReq packet (triggering 273 the probing locally) is stored in the CP table along with the 274 sequence number. 276 The message type field is set equal to the value of message type 277 "HCReq" as which is equal to '9' as mentioned in section 13. If 278 for that particular HCReq, an HCRep is received, the node must 279 send an additional HCRep to that HCReq originator address. 281 If a node receives a M-CML CP Packet described in section 6.2, it 282 MUST flood the packet in the network after decreasing its TTL 283 count. Then, the active routing algorithm part of the node MUST 284 call the relevant Adaptive part from its Adaptive component. 286 4.3. Adaptive Component 288 The Adaptive component, when activated by the m-phase (i.e., a CP 289 packet is received), the component MUST make sure the following: 291 1. The Adaptive part ID used in the calling message is valid. 293 2. The Adaptive part ID corresponds to the appropriate part with 294 respect to the active routing component if contacted from the 295 monitor part as described in the above section. 297 3. In the case where the CP packet requires that an inappropriate(see 298 point 2 above) Adaptive part be contacted, this action is ignored 299 and the CP is flooded back in the network. 301 Any of the activated Adaptive part, subsequent to the above steps, 302 MUST change operation to o-phase as it is explained in section 4.4. 304 In any other situation, the Adapt function terminates and the 305 appropriate stable phase operation is resumed. 307 4.4. Oscillation Phase 309 In the o-phase, the Adaptive component checks the o-phase validity 310 time, "Osc_Interval" of the oscillation timer described in section 311 8.1, is first checked. If the timer is still valid, the o-phase 312 variable in the core is cleared and consequently the stable phase of 313 operation is maintained. If the timer has expired, the o-phase 314 variable is set and: 316 1. If the routing algorithm ID (RID) is set to OLSRv2: 318 The OLSRv2 mechanism will continue to operate. At the same time, 319 the node will check the number of nodes in the network as 320 described in section 4. for 2 * TC_Intervals (TC_Interval is 321 described in [6]). If the number of nodes is then found to be 322 greater than L-NST at least once, the o-phase switches to r-phase 323 and resets the oscillation timer. It also generates and floods a 324 CMLv2 CP Packet. The CP packet includes its address as originator 325 address and its incremented sequence number. The CP field value of 326 the M-CML packet is set as "AODVv2 RID". 328 Otherwise, the node returns to operating in the p-phase. 330 2. If the routing algorithm ID (RID) is set to AODVv2: 332 The routing mechanism of AODVv2 will continue to operate. At the 333 same time, the Monitor and Adaptive component will check the HC of 334 the network using two more HCReq packets, as described in section 335 6.3., waiting for RREQ_WAIT_TIME * DISCOVERY_ATTEMPTS_MAX 336 (RREQ_WAIT_TIME and DISCOVERY_ATTEMPTS_MAX are explained in [3]) 337 each time. If in at least one occurrence, no HCRep is obtained for 338 the HCReq with TTL=U-NHT, it is implied that the network size is 339 smaller than the NST. In this case, the o-phase switches to p- 340 phase by clearing the o-phase variable and setting the RID to the 341 OLSRv2 RID. The oscillation timer is also reset. It also generates 342 and floods a M-CML CP packet. The CP packet includes its address 343 as originator address and its incremented sequence number. The 344 value of the CP field in the packet is set to "OLSRv2 RID". 346 Otherwise, stable r-phase routing is resumed. 348 3. If this phase shift is initiated using a M-CML CP packet: 350 The node core MUST check the value of the sequence number in the 351 packet and compare it to any stored sequence number having the 352 same originator address in the CP table. If no match is found in 353 the CP table, a new entry is created with the aforementioned 354 values obtained from the CP packet before further processing. 355 Otherwise, if a match is found and the packet sequence number is 356 less than the sequence number stored in the table, the message is 357 silently discarded and the node returns to the stable phase 358 specified by its core RID variable. 360 For non-discarded packets, the node MUST check the CP field value 361 in the CP packets and compare it with its own RID: 363 1. If they are equal, the CP packet is silently discarded and the 364 node returns to the phase specified by its core RID. 366 2. If they are not equal, the o-phase changes the RID to the value 367 specified in the CP field of the CP message and resets the 368 oscillation timer. 370 In both cases, the CP packets are flooded back in the network. 372 5. Protocol Operation 374 This section describes the behavior M-CML MUST follow in the m- 375 phase, p-phase, r-phase and o-phase. 377 5.1. M-Phase 379 In the m-phase, the node core receives packets with all message 380 types but only processes packets with message types [1-2] and routes 381 data packets as described in [8]. It also processes packets with 382 message types 9-11 as described in this draft. In addition, it sends 383 a copy of the packet to the Monitor component each time a TC routing 384 packet is received. In this phase, NST is equal to U-NST to cater 385 for group oscillation. 387 5.2. P-Phase 389 The proactive phase, i.e., p-phase, of M-CML is based on [4],[6] but 390 the source to destination route is computed differently. According 391 to [4], when a packet has to be forwarded from the source to the 392 destination, the source node acquires a path from the Multi-path 393 Routing Set, storing the path information in the datagram header as 394 source routing header. Each of the intermediate nodes, is listed in 395 the source routing header and it forwards the packet to the next hop 396 as indicated in the source routing header. 398 In our approach, each node, upon receiving a packet, computes all 399 the disjoint paths to the destination node. The next step is to 400 check if it is on the best (or 2nd, or 3rd, and so on, best) path to 401 the final destination. If this is valid, the packet is forwarded. 403 The routing decision for determining the best path will be taken by 404 using the Expected Transmission Count ETX) [7] metric. If the number 405 of paths is higher than 3, then the 3 best routes are selected 406 according to the ETX metric. So, regarding this approach the 407 decision of which path(s) is going to be selected is taken according 408 to the ETX metric instead of using the hop count metric. 410 5.3. R-Phase 412 In the r-phase, the node core receives packets with all message 413 types but processes only packets with message types 5-8 and routes 414 data packets as specified in [3]. It also processes packets with 415 message types 9-11 as described in this document. In addition, it 416 sends a copy of the packet to the Monitor component each time it 417 receives RRep routing packets as a source node. In this phase, NST 418 is equal to L-NST to cater for group oscillation. 420 5.4. O-Phase 422 In this subsection we describe the oscillation problem and the 423 operation of the o-phase as a mechanism to counteract oscillation 424 effects in MANETs that use the CMLv2 protocol. The basic operations 425 of the current stable phase still apply in the o-phase. However, 426 there are added phase dependent sampling processes to check for 427 oscillation instances. 429 5.5. Algorithm for M-CML 431 M-CML is characterized by two major modifications compared to M-CML 432 aiming to improve its operational efficiency. The first addition is 433 the incorporation of optimal M-CML configurations in the new version 434 and the second is the proposal of a new logic on the routing 435 algorithm which calculates the multiple paths in a more efficient 436 manner. 438 Multipath routing protocols can be employed to tackle challenges 439 created by link instabilities caused by environmental conditions. 440 However, it is obvious that implementing a routing protocol 441 operating in a multipath manner has some significant drawbacks 442 related to higher duplicate data packet generation, traffic 443 congestion in the network and high energy consumption. On this note, 444 we have modified the operation of our M-CML routing protocol in a 445 way of taking advantage of the multiple routes only if it is 446 absolutely necessary. Our main aim is to establish the way the 447 multipath method is performed, reduce the generation of redundant 448 duplicate packets, and apply the improved algorithm on top of the 449 changes that we considered in the previous section. In order to 450 further develop the operational efficiency of CMLv2, an extended 451 version of CMLv2 is named as M-CML. Here, M-CML protocol exploits 452 the attributes of CMLv2's system model and aims to enhance its 453 performance by applying the following changes: 455 Following up the analysis of M-ML in the p-phase, i.e., the default 456 phase, M-CML selects the optimal configuration set, with the view of 457 handling the generated routing load more effectively in the network. 459 M-CML employs the improved multipath algorithm for selectively 460 calculating multiple paths in a more efficient way, acting as a 461 single path or multipath routing protocol depending on the quality 462 of the links. This way, we aim to reduce improvident emission of 463 duplicate packets which impacts the network congestion and the 464 nodes' energy consumption. 466 The proposed algorithm describes the technique to add a new entry M- 467 CML's routing table. In particular, the set of next hop addresses 468 are listed in an ascending order based on their ETX values. Upon 469 transmitting data packets from source to destination, a gateway list 470 is responsible for allocating the corresponding routing entry to the 471 relevant destination, then parsing the ETX values which have been 472 listed in ascending order and finally transmitting the information 473 according to the two minimum ETX values. 475 Each time a node requests for a route towards the destination, it 476 first calculates all next hops corresponding to that destination. In 477 the case that there is not any available next hop, the packet is 478 eventually dropped. Otherwise, node either transmits data using the 479 two minimum values of ETX following the initial approach of M-CML, 480 or dynamically decides to transmit data using a single path only if 481 the ETX value is on its minimum value, i.e., ETX=1. This can reduce 482 the unnecessary copies of the same packets which are distributed 483 throughout the network due to the multipath attributes of the 484 protocol and, at the same time, confine the energy consumption. 485 Moreover, during the scenarios where the distance among source and 486 destination is limited and the successful delivery of HELLO messages 487 is high, we aim to eliminate the improvident emission of redundant 488 information. 490 5.5.1. Protocol Operation 492 M-CML proposes a twofold solution to the oscillation problem. 493 Appropriate NSL values (acting as NST) can restrain the effects of 494 group oscillations whereas the right "Osc_Interval" value for the 495 oscillation timer limits the impact of frequent oscillations. 497 In addition, during the o-phase, the monitor component samples more 498 instances of the 'number of nodes' count or the network HC 499 (depending on the current stable phase of operation) as described in 500 section 4. In this way, it can confirm whether the NST or NHT has 501 actually been exceeded. Otherwise, it determines that an oscillation 502 has occurred and the stable phase of operation is resumed. If the 503 NST is found to have been actually exceeded in the o-phase, the 504 appropriate part of the Adaptive component (identified as explained 505 above) resets the oscillation timer and generates CP packets. These 506 CP packets are flooded into the network to alert neighboring nodes 507 of such a phase shift. The o-phase is then terminated by the 508 Adaptive Component part that then shifts routing operation to the 509 relevant stable phase of operation. 511 Furthermore, during the o-phase, the core and active Adaptive 512 component part are responsible for phase shifting if a valid CP 513 packet is received from a neighboring node (as explained above). In 514 such a case, it floods back the CP packet in the network. 516 Furthermore, during the o-phase, the core and active Adaptive 517 component part are responsible for phase shifting if a valid CP 518 packet is received from a neighboring node (as explained above). In 519 such a case, it floods back the CP packet in the network. If the 520 protocol phase changes from p-phase to r-phase, and a HELLO packet 521 is received, the information about next hop is stored in the routing 522 table. A TC packet information is used to either reset a timeout in 523 the routing table or populate routing table information for 524 potential data to be sent. In the case where the transition occurs 525 from the r-phase to the p-phase, and RREQ are requested, if the 526 destination is already in the routing table, a RREP is sent back 527 with this information. Otherwise, the RREQ is stored until 2 528 *TC_INTERVAL before sending a RREP. 530 6. M-CML Packet and Message Formats 532 6.1. Packet Format 534 The basic layout of a M-CML packet is as recommended in [12]. The 535 message type field indicates the type of message found in the 536 "MESSAGE" section. This could be a M-CML message or messages from 537 [6] or [3] or the CP message. 539 6.2. Change Phase (CP) Message 541 The Change Phase (CP) field contains the RID to which the originator 542 node has shifted to and subsequently requests neighbor nodes to 543 shift to. 545 The Change Phase message format is shown below: 547 0 1 2 3 549 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 553 | CP containing RID | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 557 6.3. Hop Count Request (HCReq) Message 559 The HCReq message has an empty message body. It can be identified as 560 a CML packet with: 562 o Message Type - The value of message type is set to 9. 564 o TTL - The TTL value is set to NHT. 566 6.4. Hop Count Request (HCRep) Message 568 The message format for the HCRep message is: 570 0 1 2 3 572 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Destination IP address | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Destination Sequence Number | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 o Destination IP address - Originator IP address in corresponding 585 HCReq packet. 587 o Destination Sequence Number - Originator Sequence Number of 588 corresponding HCReq packet. 590 7. M-CML tables 592 7.1. M-CML Change Phase table 594 The M-CML CP Table fields are listed below: 596 o Originator IP Address - The IP address of the node which generated 597 the packet. 599 o Originator Sequence Number - The Sequence number of the message 600 that was sent by the node which generated the packet. This is 601 incremented monolithically for each message generated by a node. 603 o Message Type - The message type value of the message through which 604 the table row was populated. 606 8. M-CML Timers 608 8.1. Oscillation timer 610 The Oscillation timer is used in the o-phase to prevent phase shifts 611 within the time period of "Osc_Interval". This timer prevents phase 612 shift due to frequent oscillations. 614 9. Constants 616 9.1. Network Threshold Values 618 The Network threshold values for M-CML are described below: 620 o NST - The theoretical Network size threshold "Nt" of a network 621 depends on the number of nodes N in the network, the critical area A 622 of the network and the radio coverage area of each node. NST marks 623 the point after which a reactive routing approach will be more 624 effective (in terms of end to end packet delivery latency) and 625 efficient (in terms of battery usage) compared to a reactive routing 626 approach. 628 Below the NST point, proactive routing approaches outperform 629 reactive routing approaches. 631 o U-NST - The Upper limit network size threshold "Nu" is given by: 633 Nu = Nt + Nosc 635 where "Nosc" is the number of nodes in the network which are 636 expected to oscillate. 638 When operating in the p-phase the actual value of NST is equal to 639 "Nu". 641 o L-NST - The Lower limit network size threshold "Nl" is given by: 643 Nl = Nt - Nosc 645 When operating in the r-phase the actual value of NST is equal to 646 "Nl". 648 o NHT - The network hop threshold value "Nht" is directly 649 proportional to the square root value of the NST: 651 Nht = Function (sqrt (Nt)) 653 The optimal values for "Nt", "Nosc", "Nu", "Nl" and "Nht" as well as 654 an accurate relationship between NST and NHT can be derived through 655 experimentation and mathematical modeling for a given critical area, 656 'A' and node coverage radius 'R'. 658 9.2. Oscillation Interval (Osc_Interval) 660 The Osc_Interval is a time period for which no phase shift is 661 allowed. While the U-NST and L-NST values cater for group 662 oscillations, the Osc_Interval prevents unnecessary phase shift 663 overheads due to regular oscillations. Thus, the Osc_Interval SHOULD 664 be set according to the time period of node oscillations. The 665 optimal value for Osc_Interval can be derived through 666 experimentation and mathematical modeling for a given critical area, 667 'A' and node coverage radius 'R'. 669 9.3. Parameters Value 671 Parameter values used by the M-CML protocol and also defined in [3] 672 and [6] are: 674 Parameter Name Value 676 ---------------------- ----- 678 RREQ_WAIT_TIME 2 seconds 680 DISCOVERY_ATTEMPTS_MAX 3 attempts 682 RREQ_HOLDDOWN_TIME 10 seconds 684 HELLO_INTERVAL 2 seconds 686 TC_INTERVAL 5 seconds 688 10. Message Emission and Jitter 690 Synchronization of control messages SHOULD be avoided as mentioned 691 in [2]. 693 11. IPv6 Considerations 695 All the operations and parameters described in this document can be 696 used for both IP version 4 and IP version 6. For IPv6 networks, the 697 IPv4 addresses in M-CML packets and messages need to be replaced by 698 IPv6 addresses. The packet and message sizes will also increase 699 accordingly. 701 12. Security Considerations 703 M-CML does not specify any security countermeasures. Security 704 Threats for OLSRv2 are described in IETF draft, Security Threats for 705 the Optimized Link State Routing Protocol Version 2 (OLSRv2) [10] 706 and for the Ad-Hoc On-demand Distance Vector Version 2 (AODVv2)[3] 707 which are applicable to MCML. 709 M-CML Packet/Message Format follow the Generalized Mobile Ad Hoc 710 Network (MANET) Packet/Message Format proposed in [12]. Hence the 711 security mechanisms suggested in [12] and [15] can be directly 712 applied to this protocol. The network performance can also be 713 affected by artificial manipulation of metric values. More specific, 714 if a link is, artificially, advertised with a higher value, the 715 amount of incoming traffic may be reduced. A malicious node, might 716 decrease or increase the value of the advertised links, in order to 717 increase or decrease the data traffic. Thus, a malicious node can 718 potentially affect data throughput, by not sending data from good 719 links and vice versa. 721 13. IANA Considerations 723 The IANA consideration section is required as recommended by [11] 724 and [13]. The following values for the corresponding message types 725 would be required: 727 Message Type Value 729 -------------------- ----- 731 HELLO_MESSAGE = 1 733 TC_MESSAGE = 2 735 ROUTE REQUEST (RREQ) = 3 737 ROUTE REPLY (RREP) = 4 739 ROUTE ERROR (RERR) = 5 741 ROUTE-REPLY ACK (RREP-ACK) = 6 743 HOP COUNT REQUEST (HCREQ) = 7 745 HOP COUNT REPLY (HCREP) = 8 747 CHANGE PHASE (CP) = 9 749 14. Conclusions 751 This I-D introduced the M-CML routing protocol. Here, M-CML is a 752 routing protocol which combines the functionalities of Multipath 753 OLSRv2 and AODVv2 protocols in an adaptive and hybrid manner. The 754 motivation behind M-CML is the enhancement and the increase of the 755 reliability and robustness of the networks. The main features of 756 MCML include the Adaptive Module, which monitors and adapts, within 757 m-phase, to the changing network state, the p-phase which computes 758 multiple routes according to the link quality metric (ETX), the r- 759 phase which is computes multiple routes in an on-demand manner. In 760 the next release, M-CML will be enhanced by removing the o-phase and 761 will operate as a single protocol. Furthermore, M-CML will consider 762 various route optimization to improve the mobility support. 764 15. References 766 15.1. Normative References 768 [1] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [2] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 772 considerations in MANETs", RFC 5148, March 2008. 774 [3] Perkins, et al., "Dynamic MANET On-demand (AODVv2) Routing", 775 IETF Draft, December 2014. 777 [4] Yi,J. and Parrein,B., "Multi-path Extension for the Optimized 778 Link State Routing Protocol version 2 (OLSRv2) ", IETF Draft, 779 October 2014. 781 [5] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): 782 Routing Protocol Performance Issues and Evaluation 783 Considerations", RFC 2501, January 1999. 785 [6] Clausen, T., Dearlove, C., Jacquet, P., Herberg, U., "The 786 Optimized Link State Routing Protocol Version 2", RFC 7181, 787 April 2014. 789 [7] Vasseur, JP., Kim, M., Pister, K., Dejean, N., Barthel, D., 790 "Routing Metrics Used for Path Calculation in Low? Power and 791 Lossy Networks", RFC 6551, March 2012. 793 [8] Ramrekha, A., Panaousis, E., Politis, C., "ChaMeLeon (CML): A 794 hybrid and adaptive routing protocol for Emergency 795 Situations", IETF Draft March 2011. 797 [9] Ladas, A., Deepak, G.C., Pavlatos, N. and Politis, C., 2018. 798 "A selective multipath routing protocol for ubiquitous 799 networks" Ad Hoc Networks, 77, pp.95-107, August 2018. 801 15.2. Informative References 803 [10] Clausen, T., Herberg, U., Yi, J., "Security Threats for the 804 Optimized Link State Routing Protocol version 2 (OLSRv2) ", 805 IETF Draft, August 2014. 807 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 808 Considerations Section in RFCs", RFC 5226, BCP 26, May 2008. 810 [12] Clausen, T., Dean, J., Dearlove, C., and Adjih, C."Generalized 811 MANET Packet/Message Format", RFC 5444, March 2009. 813 [13] Chakeres, I., "IANA Allocations for MANET Protocols", RFC 814 5498, March 2009. 816 [14] Clausen, T. and C. Dearlove, "Representing multi-value time in 817 MANETs", RFC 5497, March 2009. 819 [15] Herberg, U., Dearlove, C., Clausen, T., "Integrity Protection 820 for the Neighborhood Discovery Protocol (NHDP) and Optimized 821 Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, 822 April 2014. 824 16. Acknowledgments 826 The authors wish to acknowledge the support of the Engineering and 827 Physical Science Research Council (EPSRC) Project DARE (Distributed 828 Autonomous Resilient Emergency Management System) under the grant 829 agreement number EP/P028764/1. Framework Program and all the 830 partners in SALUS (Security And InteroperabiLity in Next Generation 831 PPDR CommUnication InfrastructureS)project with contract number 832 313296 and also the support of the ICT European 7th Framework 833 Program and all partners in PROACTIVE PRedictive reasOning and 834 multi-source fusion empowering AntiCipation of attacks and Terrorist 835 actions In Urban EnVironmEnts with contract number 285320. 837 This document was prepared using 2-Word-v2.0.template.dot. 839 Authors' Addresses 841 The following researchers who have contributed to this I-D are 842 members of the Wireless Multimedia and Networking (WMN) Research 843 Group at Kingston University London: 845 Alexandros Ladas 847 Researcher 849 Researcher, WMN Research Group 851 Kingston University London, UK, KT1 2EE 853 Phone: (+44) 02084177025 855 Email: k1242116@kingston.ac.uk 857 Deepak G C 859 Research Fellow, WMN Research Group 861 Kingston University London, UK, KT1 2EE 863 Phone: (+44)02084177025 865 Email: d.gc@kingston.ac.uk 867 Nuwan Weerasinghe 869 Researcher, WMN Research Group 871 Kingston University London, UK, KT1 2EE 872 Phone: (+44) 02084177025 874 Email: n.weerasinghe@kingston.ac.uk 876 Christos Politis 878 Head of WMN Research Group 880 Kingston University London, UK, KT1 2EE 882 Phone: (+44) 02084172653 884 Email: c.politis@kingston.ac.uk