idnits 2.17.1 draft-ramrekha-manet-cml-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 : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date () is 739371 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 895, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 902, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ramrekha-manet-cam-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '8') (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF MANET Working Group T. Ramrekha 2 Internet-Draft E. Panaousis 3 Intended status: Experimental C. Politis 4 Expires: February 2011 WMN Research Group 5 Kingston University London 6 AUG 25, 2010 8 ChaMeLeon (CML): A hybrid and adaptive routing protocol for Emergency 9 Situations 10 draft-ramrekha-manet-cml-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 19 10, 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on February 27, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 Abstract 60 This document describes the ChaMeLeon (CML) routing protocol 61 designed for Mobile Ad hoc NETworks (MANETs) supporting emergency 62 communications. CML is a hybrid and adaptive routing protocol 63 operating within a defined disaster area denoted as the Critical 64 Area (CA). The main concept behind CML is the adaptability of its 65 routing mechanisms towards changes in the physical and logical state 66 of a MANET. For autonomous emergency communications, there is a 67 likelihood that the network size will vary whenever more rescuers 68 join or leave the network. In addition, battery exhaustion of 69 lightweight mobile communication devices used by rescuers could 70 stipulate another reason for changes in the network size. Hence, 71 this version of CML adapts its routing behavior according to changes 72 in the network size within a pre-defined CA. For small networks, CML 73 routes data proactively using the Optimized Link State Routing 74 (OLSR) protocol whereas for larger networks it utilizes the reactive 75 Ad hoc On-Demand Distance Vector (AODV) Routing protocol so that 76 overall routing performance is improved. These transitions occur via 77 the CML oscillation phase. This document focuses on the description 78 of the processes involved in the CML Cognitive and Adaptive Module 79 (CAM), CML Oscillation phase and transition between phases. 81 Table of Contents 83 1. Introduction ................................................ 3 84 2. Conventions used in this document............................ 4 85 2.1. CML Terminology......................................... 4 86 3. Applicability ............................................... 8 87 4. Protocol Overview ........................................... 8 88 4.1. CML operation with CAM.................................. 9 89 4.1.1. CAM core .......................................... 9 90 4.1.2. Monitor Component................................. 10 91 4.1.3. Adaptive Component................................ 11 92 4.2. O-phase ............................................... 12 93 5. Protocol Operation ......................................... 13 94 5.1. P-phase ............................................... 14 95 5.2. R-phase ............................................... 14 96 5.3. O-phase ............................................... 14 97 5.3.1. The Oscillation Problem........................... 14 98 5.3.2. Operation ........................................ 15 99 6. CML Packet and Message Formats.............................. 15 100 6.1. Packet Format ......................................... 15 101 6.2. Change Phase (CP) Message.............................. 15 102 6.3. Hop Count Request (HCReq) Message...................... 16 103 6.4. Hop Count Request (HCRep) Message...................... 16 104 7. CML tables ................................................. 16 105 7.1. CML Change Phase table................................. 16 106 8. CML Timers ................................................. 17 107 8.1. Oscillation timer...................................... 17 108 9. Constants .................................................. 17 109 9.1. Network Threshold Values............................... 17 110 9.2. Oscillation Interval (Osc_Interval).................... 18 111 9.3. Parameter Values....................................... 18 112 10. Message Emission and Jitter................................ 18 113 11. IPv6 Considerations........................................ 18 114 12. Security Considerations.................................... 19 115 13. IANA Considerations........................................ 19 116 14. Conclusions ............................................... 20 117 15. References ................................................ 21 118 15.1. Normative References.................................. 21 119 15.2. Informative References................................ 21 120 16. Acknowledgments ........................................... 22 122 1. Introduction 124 This protocol is an adaptive and hybrid routing protocol for MANETs 125 designed to be used by rescuers within the realm of extreme 126 emergency communications. It consists of 3 phases of operation 127 namely Proactive, Oscillation and Reactive. The Proactive (p-) and 128 Reactive (r-) phases operate in the same way as the core functions 129 of [3] and [6] respectively and are discrete from each other. The 130 Oscillation phase (o-phase), therefore, acts as an intermediate 131 between p- and r-phases and decides on whether a shift from p-phase 132 to r-phase is appropriate based on criteria defined in section 4.2. 134 The main purpose of the o-phase is to avoid the oscillation problem 135 as described in section 5.3. In addition, ChaMeLeon (CML) uses the 136 Cognitive and Adaptive module (CAM) specified in [4]. The module is 137 designed to segment routing protocols into logical parts for an 138 easier and . monitor relevant MANET characteristics, detect a 139 certain quantitative threshold exhibited by specific monitored 140 characteristics and in such an event, transfer the control to the o- 141 phase. 143 This version of CML monitors the number of nodes in MANETs within a 144 defined Critical Area (CA) where extreme emergency rescue operations 145 take place. In such a situation, rescuers tend to join or leave the 146 network according to the severity of the situation. CML aims to 147 adapt its routing mechanism to the size of such MANETs, thus 148 enhancing overall efficiency and effectiveness (both terms defined 149 in [5]) as compared to [3] and [6]. CML uses [6], [3], [9], [11] 150 and, optionally, [1]. CML makes no assumptions about the underlying 151 link layer. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC-2119 [1]. 159 2.1. CML Terminology 161 This section defines terminology associated with CML that is not 162 already defined in or that differs from the meaning of the 163 terminology in [9], [6] [4]and [3]. 165 o Node - A MANET router that implements the CML protocol as 166 specified in this document. 168 o CML interface - A network device that participates in a MANET 169 that runs CML. A node may have several CML interfaces. Each 170 interface SHOULD be assigned a unique IP address. Each interface 171 SHOULD have a unique IP address. 173 o Non CML interface - A network device that does not participate in 174 a MANET that runs CML. A node MAY have several non CML 175 interfaces. 177 o Single CML interface node - A node in a MANET that has only one 178 CML interface. 180 o Multiple CML interface node - A node in a MANET that has more 181 than one CML interface. 183 o Link - A pair of CML interfaces, from two different nodes, within 184 the same radio range that can communicate directly with each 185 other. A node has a link to another node when at least one of its 186 interfaces has a link to one of the interfaces of the other node. 188 o Symmetric link - A verified bi-directional link between two CML 189 interfaces. 191 o Asymmetric link - A verified link between two CML interfaces in 192 one direction only. 194 o Main address - The main address of a node, to be used in CML 195 packet as the "originator address" for all control messages 196 generated by the node. It MUST be the address of one of the CML 197 node interfaces. 199 o Neighbor node - A node X is a neighbor node of node Y if node Y 200 can hear node X. 202 o MANET Context - A set of characteristics describing the MANET and 203 its environment as defined in [5]. This includes node mobility 204 levels, small and large node groups as well as technological and 205 environmental constraints such as limited battery life of devices 206 and bandwidth limitations of wireless links. 208 o Source - A node that initiates data communication in the network 209 or a node which generates control packets. 211 o Sink - A node that is the intended recipient of data sent by 212 source nodes. 214 o Router - A node that implements the CML protocol. All 215 collaborating nodes are potential routers. Router nodes are 216 intermediate nodes located on routes between source and 217 destination nodes. They are responsible for forwarding packets 218 according to the CML routing algorithm. 220 o Source address - An address that is unique (within the MANET) to 221 each individual source node. A node MUST select an originator 222 address; it MAY choose one of its interface addresses as its 223 originator address. 225 o Destination address - An address that is unique (within the 226 MANET) to each individual sink node. 228 o Operation phase - A state of node operation that results from a 229 number of logical parts of the routing protocol being active. 231 o Stable phases - The set of CML routing phases that operates 232 efficiently for a given MANET context. In this CML version, r- 233 phase and p-phase are the only stable phases. 235 o R-phase - A routing phase where the protocol adopts routing 236 mechanisms from [3]. 238 o P-phase - A routing phase where the protocol adopts routing 239 mechanisms from [6]. 241 o CML Oscillation phase - A routing phase where the protocol 242 continues to operate in the current stable phase. It also checks 243 whether the network size or hop threshold has been genuinely 244 exceeded or whether node oscillation has taken place. It also 245 alerts neighbors whenever it decides that the network has to 246 shift phases. This phase is initiated by the CML Adaptive module. 248 o Phase-shift - A shift from r-phase routing to p-phase routing via 249 the o-phase. 251 o Oscillation - An event where at least one node regularly joins 252 and leaves a MANET so that the CML Network Size Threshold is each 253 time exceeded by such activity. 255 o Cognitive and Adaptive Module (CAM) - A module that encompasses 256 all the logics of CML functionality including Monitoring and 257 Adaptation. This module activates logics according to network 258 contexts. It MAY be used to determine the number of nodes in the 259 network and check whether this number has breached Network Size 260 Limits. It also change the node phase to o-phase if the threshold 261 is exceeded. A generic CAM is described in [4]. 263 o CML Network Size Threshold (NST) - A threshold for the number of 264 nodes in the network. Below the NST point, p-phase routing is 265 more efficient and effective (both terms defined in [5]) than the 266 r-phase routing. Beyond the NST point, r-phase routing 267 outperforms p-phase. The NST varies according to the context of 268 the MANET such as transmission range of the devices and node 269 density (for a given critical area). NST is exceeded in the r- 270 phase when the number of nodes is less than NST. In the p-phase, 271 this occurs when the number of nodes is greater than NST. 273 o CML Network Size Limit (NSL) - The NSL is a couple of values 274 which deviate by an equal amount greater/less than the NST. The 275 Upper value of NST is denoted by (U-NST) and the Lower value by 276 (L-NST). The deviation value from Network Size Threshold is 277 selected based on node oscillation properties. 279 o CML Change Phase (CP) packet - A control packet unique to CML 280 that is sent during the o-phase to alert other nodes in the 281 network that a phase-shift has occurred locally. In p-phase mode, 282 CML CP packets are only forwarded by MPR nodes whereas in r-phase 283 mode, the CP packets are flooded by all nodes in an RREQ flooding 284 fashion. 286 o CML Change Phase (CP) Table - The CP Table is used to make sure 287 that the originator sequence number and originator IP information 288 of processed CML control packets are available for a given 289 timeout period. This will help in ensuring loop free 290 communication. 292 o Network Hop Threshold (NHT) - A hop count value which indicates 293 that the NST has been reached. The relationship between NHT and 294 NST is defined in section 9.1. 296 o CML Hop Count Request (HCReq) Packet - A CML control packet sent 297 to probe whether the Network Hop Threshold (NHT) has been 298 exceeded. 300 o CML Hop Count Reply (HCRep) Packet - A CML control packet sent as 301 a unicast reply to a HCReq packet. When it is received by the 302 originator node, it indicates that the Network Hop Threshold 303 (NHT) has not been exceeded. 305 3. Applicability 307 This protocol has been designed with Ad hoc Communications in 308 extreme emergency scenarios in mind, where rescuers are equipped 309 with lightweight communication devices. The autonomous nature of 310 MANETs is very suitable for extreme emergency communications within 311 the CA because communication infrastructures in such disaster sites 312 are usually incapacitated. Also, in such a context, the number of 313 MANET nodes varies depending on the severity of the rescue 314 operations. In such extreme emergencies: 316 . Battery limitation of nodes is a very important consideration. 317 Node failure as a consequence of battery drainage MAY result 318 in network segmentation and thus compromise rescue operations. 320 . Nodes MAY join or leave the network according to the urgency 321 of the situation and vary network size 323 . A certain quality of service (QoS) level has to be maintained 324 to allow for multimedia communication. Mainly, certain delay 325 bounds have to be established while also maintaining effective 326 routing by minimizing battery consumption. 328 . Rescuers MAY not always desire to communicate with each other, 329 therefore, maintaining proactive routes in all situations MAY 330 not always be the best routing option. 332 CML has the ability to adapt its routing behavior to changes in 333 MANET size. Hence, it is a more suitable routing alternative than 334 pure routing approaches for small, large as well as variable sized 335 MANETs operating in a defined CA. A MANET including but not limited 336 to such unique contextual considerations is defined as an emergency 337 MANET (eMANET) in [7]. Future versions of CML will include functions 338 in the Adaptive module to adapt to some of the other eMANET contexts 339 such as mobility and those described in [5]. In this document, it is 340 assumed that nodes are uniformly distributed in the CA so that 341 rescuers can cover the maximum CA. 343 In addition, CML MAY also be used for general purpose MANETs as it 344 utilizes CAM to adapt to specific network contexts. 346 4. Protocol Overview 348 This protocol is designed to work as a hybrid and adaptive routing 349 protocol for eMANETs. The normal mode of operation is under one of 350 the stable phases. The default stable operating phase is the p- 351 phase. This section describes the various processes and structures 352 introduced by CML. Thus, it focuses on the interaction between the 353 routing logics encompassed by CAM most notably the operation during 354 the o-phase. The routing behaviors of the r-phase and p-phase have 355 been described in [3] and [6] respectively. Here, these routing 356 states are described with respect to usage within CAM. 358 4.1. CML operation with CAM 360 The operation of CML is described in this section. An overview of 361 the protocol is shown in Figure 1. 362 +------------------------------------------------------------------------+ 363 | +-----+ +-------+ +------+ +-------+ +------+ +----+ +------+| 364 | |Net. | |Size | |L-NST | |U-NST | |OLSR | |AODV| |Tables|| 365 | |Size | |O-phase| |Limit | | Part | | | | | | || 366 | +-----+ +-------+ +------+ +-------+ +------+ +----+ +------+| 367 | A | A | A | A | A | A | A | | 368 | | v | v | v | v | v | v | v | 369 |+--------------+ +-----------------+ +-----------------+ +--------+ | 370 || Monitor | | Adaptive | | Routing Algo. | | Repo. | | 371 |+--------------+ +-----------------+ +-----------------+ +--------+ | 372 | A | A | A | A | | 373 | | | | | | | | | | 374 | | v | v | v | v | 375 | +-------------------------------------------------------------------+ | 376 | | CAM CORE | | 377 | | Fine Variables | | 378 | | Coarse Variables | | 379 | | In/Out Component Interfaces | | 380 | | In/Out Packet interfaces | | 381 | +-------------------------------------------------------------------+ | 382 +------------------------------------------------------------------------+ 384 Figure 1 : Overview of the updated CML protocol with CAM 386 4.1.1. CAM core 388 The CAM core contains variables that identify at least one active 389 part from each component. Thus, as defined in [4], a bitwise scheme 390 can be used to assign IDs to active components. The required 391 variables include the Monitor ID, Adaptive ID, Routing Algorithm ID, 392 Security ID, Repository Routing Table IDs and Repository packet 393 definition IDs. The o-phase variable is defined and maintained to 394 signal whether the o-phase processes have to be activated as 395 described in later sections. 397 4.1.2. Monitor Component 399 When a control message is received at the CAM core interface, the 400 node MUST: 402 1. Send a copy of the packet to the monitor part of the module. 403 The monitor component has a network size part that MUST check 404 the number of nodes in the network. This is accomplished 405 differently depending on the current stable phase of operation 406 (as described later). 408 2. Send the the packet to the regular control message processing 409 by the stable phase, as described in [3] or [6]. The current 410 active routing part. 412 The monitor part determines the network size as follows. In the p- 413 phase (where the OLSR routing algorithm is active), this task 414 consists of calculating the number of reachable hosts from the 415 routing table as defined in [6]. This calculation is done by 416 counting the number of rows in the proactive routing table. Each row 417 includes fields of; possible destination nodes, the next hop to 418 reach the destination as specified in the possible destination field 419 and its distance from the current source node. These field values 420 are computed using periodical Topology Control (TC) and HELLO 421 message broadcasts by each node in the network. If the number of 422 nodes is found to exceed the NST, this monitor part must contact the 423 L-NST part of the Adaptive Component. 425 In the r-phase (where the AODV routing algorithm is active), the 426 number of nodes in the network is estimated using the maximum value 427 of the hop count from a source node to a destination. As defined in 428 [3], a source finds a route to a destination 'on-demand' by flooding 429 a Route Request (RReq) packet throughout the network using an 430 expanding ring approach until a RRep is received from the 431 destination. The monitor function in the source node must use this 432 RRep message to obtain the value of Hop Count (HC) towards the 433 destination node. It then compares this with the U-NST, which is 434 calculated according to the relationship defined in section 9.1. The 435 monitor function MUST act as follows: 437 1. If HC in RRep is greater or equal to U-NST, it decides that the 438 NST is not exceeded. 440 2. If HC in RRep is less than the U-NST, the data packets are 441 transmitted through the established route. After data 442 transmission, the CML Hop Count Request (HCReq) packet described 443 in section 6.3. MUST be generated and flooded in the network to 444 probe for the network HC (as opposed to destination HC). The HC 445 is said to be less than the NHT, if after 4*NET_TRAVERSAL_TIME, 446 no HCRep has been received. If the HC is less than the U-NST, the 447 monitor function decides that the r-phase NST (calculated using 448 the relationship in section 9.1. ), has been exceeded and calls 449 the U-NST part of the Adaptive component. 451 If a node receives HCReq, it must first make sure that the sequence 452 number of the packet is greater than that stored in the Change Phase 453 (CP) table for the same originator address. Then, it checks if the 454 TTL = 0. If the latter is true, it MUST store HCReq originator IP 455 and packet sequence number information in the CP table and send back 456 an HCRep to the originator, as described in section 6.4. Otherwise, 457 it decreases the TTL value and floods back the HCReq packet in the 458 network. It then generates and floods its own HCReq to probe for the 459 HC with TTL value set to NHT. The value of the originator address of 460 the original HCReq packet (triggering the probing locally) is stored 461 in the CP table along with the sequence number. The message type 462 field is set equal to the value of message type "HCReq" as which is 463 equal to '9' as mentioned in section 13. If for that particular 464 HCReq, an HCRep is received, the node must send an additional HCRep 465 to that HCReq originator address. 467 If a node receives a CML CP Packet described in section 6.2. , it 468 MUST flood the packet in the network after decreasing its TTL count. 469 Then, the active routing algorithm part of the node MUST call the 470 relevant Adaptive part from its Adaptive component. 472 4.1.3. Adaptive Component 474 The Adaptive component, when called by the monitor or core (in case 475 a CP packet is received) component MUST sure of the following: 477 1. The Adaptive part ID used in the calling message is valid. 479 2. The Adaptive part ID corresponds to the appropriate part with 480 respect to the active routing component if contacted from the 481 monitor part as described in the above section. 483 3. In the case where the CP packet requires that an inappropriate 484 (see point 2 above) Adaptive part be contacted, this action is 485 ignored and the CP is flooded back in the network. 487 Any of the activated Adaptive part, subsequent to the above steps, 488 MUST change operation to o-phase. 490 In any other situation, the Adapt function terminates and the 491 appropriate stable phase operation is resumed. 493 4.2. O-phase 495 In the o-phase, the Adaptive component checks the o-phase validity 496 time, "Osc_Interval" of the oscillation timer described in section 497 8.1. , is first checked. If the timer is still valid, the o-phase 498 variable in the core is cleared and consequently the stable phase of 499 operation is maintained. If the timer has expired, the o-phase 500 variable is set and: 502 1. If the routing algorithm ID (RID) is set to OLSR: 504 The OLSR mechanism will continue to operate. At the same time, 505 the node will check the number of nodes in the network as 506 described in section 4. for 2*TC_Intervals (TC_Interval is 507 described in [6]). If the number of nodes is then found to be 508 greater than L-NST at least once, the o-phase switches to r-phase 509 and resets the oscillation timer. It also generates and floods a 510 CML CP Packet. The CP packet includes its address as originator 511 address and its incremented sequence number. The CP field value 512 of the CML packet is set as "AODV RID". 514 Otherwise, the node returns to operating in the p-phase. 516 2. If the routing algorithm ID (RID) is set to AODV: 518 The routing mechanism of AODV will continue to operate. At the 519 same time, the Monitor and Adaptive component will check the HC 520 of the network using two more HCReq packets, as described in 521 section 6.3. , waiting for 4*NET_TRAVERSAL_TIME 522 (NET_TRAVERSAL_TIME is explained in [3]) each time. If in at 523 least one occurrence, no HCRep is obtained for the HCReq with 524 TTL=U-NHT, it is implied that the network size is smaller than 525 the NST. In this case, the o-phase switches to p-phase by 526 clearing the o-phase variable and setting the RID to the OLSR 527 RID. The oscillation timer is also reset. It also generates and 528 floods a CML CP packet. The CP packet includes its address as 529 originator address and its incremented sequence number. The value 530 of the CP field in the packet is set to "OLSR RID". 532 Otherwise, stable r-phase routing is resumed. 534 3. If this phase shift is initiated using a CML CP packet: 536 The node core MUST check the value of the sequence number in the 537 packet and compare it to any stored sequence number having the 538 same originator address in the CP table. If no match is found n 539 the CP table, a new entry is created with the aforementioned 540 values obtained from the CP packet before further processing. 541 Otherwise, if a match is found and the packet sequence number is 542 less than the sequence number stored in the table, the message is 543 silently discarded and the node returns to the stable phase 544 specified by its core RID variable. 546 For non-discarded packets, the node MUST check the CP field value in 547 the CP packets and compare it with its own RID: 549 1. If they are equal, the CP packet is silently discarded and the 550 node returns to the phase specified by its core RID. 552 2. If they are not equal, the o-phase changes the RID to the value 553 specified in the CP field of the CP message and resets the 554 oscillation timer. 556 In both cases, the CP packets are flooded back in the network. 558 5. Protocol Operation 560 This section describes the behavior CML MUST follow in the p-phase, 561 r-phase and o-phase. 563 5.1. P-phase 565 In the p-phase, the node core receives packets with all message 566 types but only processes packets with message types 1-4 and routes 567 data packets as described in [6]. It also processes packets with 568 message types 9-11 as described in this document. In addition, it 569 sends a copy of the packet to the Monitor component each time a TC 570 routing packet is received. 572 In this phase, NST is equal to U-NST to cater for group oscillation 573 as described in section 5.3.1. 575 5.2. R-phase 577 In the r-phase, the node core receives packets with all message 578 types but processes only packets with message types 5-8 and routes 579 data packets as specified in [3]. It also processes packets with 580 message types 9-11 as described in this document. In addition, it 581 sends a copy of the packet to the Monitor component each time it 582 receives RRep routing packets as a source node. 584 In this phase, NST is equal to L-NST to cater for group oscillation. 586 5.3. O-phase 588 In this subsection we describe the oscillation problem and the 589 operation of the o-phase as a mechanism to counteract oscillation 590 effects in eMANETs that use CML. The o-phase can only be initiated 591 by the Adaptive module as described in section 4.1. The basic 592 operations of the current stable phase still apply in the o-phase. 593 However, there are added phase dependent sampling processes to check 594 for oscillation instances. 596 5.3.1. The Oscillation Problem 598 Oscillation occurs when nodes join and leave the network repeatedly 599 so that the total number of nodes fluctuates, exceeding and 600 returning below the NST, on a sequential basis. This causes 601 performance degradation in CML due to frequent phase shifts. The 602 oscillation level is characterized by: 604 1. The number of nodes that oscillates 606 2. The frequency at which nodes oscillate 608 5.3.2. Operation 610 CML proposes a twofold solution to the oscillation problem. 611 Appropriate NSL values (acting as NST) can restrain the effects of 612 group oscillations whereas the right "Osc_Interval" value for the 613 oscillation timer limits the impact of frequent oscillations. 615 In addition, during the o-phase, the monitor component samples more 616 instances of the 'number of nodes' count or the network HC 617 (depending on the current stable phase of operation) as described in 618 section 4. In this way, it can confirm whether the NST or NHT has 619 actually been exceeded. Otherwise, it determines that an oscillation 620 has occurred and the stable phase of operation is resumed. If the 621 NST is found to have been actually exceeded in the o-phase, the 622 appropriate part of the Adaptive component (identified as explained 623 above) resets the oscillation timer and generates CP packets. These 624 CP packets are flooded into the network to alert neighboring nodes 625 of such a phase shift. The o-phase is then terminated by the 626 Adaptive Component part that then shifts routing operation to the 627 relevant stable phase of operation. 629 Furthermore, during the o-phase, the core and active Adaptive 630 component part are responsible for phase shifting if a valid CP 631 packet is received from a neighboring node (as explained above). In 632 such a case, it floods back the CP packet in the network. 634 6. CML Packet and Message Formats 636 6.1. Packet Format 638 The basic layout of a CML packet is as recommended in [9]. The 639 message type field indicates the type of message found in the 640 "MESSAGE" section. This could be a CML message or messages from [6] 641 or [3] or the CP message. 643 6.2. Change Phase (CP) Message 645 The Change Phase message format is shown below: 647 0 1 2 3 648 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | CP containing RID | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 o Change Phase (CP) - The CP field contains the RID to which the 655 originator node has shifted to and subsequently requests neighbor 656 nodes to shift to. 658 6.3. Hop Count Request (HCReq) Message 660 The HCReq message has an empty message body. It can be identified as 661 a CML packet with: 663 o Message Type - The value of message type is set to 9. 665 o TTL - The TTL value is set to NHT. 667 6.4. Hop Count Request (HCRep) Message 669 The message format for the HCRep message is: 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Destination IP address | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Destination Sequence Number | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 o Destination IP address - Originator IP address in corresponding 680 HCReq packet. 682 o Destination Sequence Number - Originator Sequence Number of 683 corresponding HCReq packet. 685 7. CML tables 687 7.1. CML Change Phase table 689 The CML CP Table fields are listed below: 691 o Originator IP Address - The IP address of the node which 692 generated the packet. 694 o Originator Sequence Number - The Sequence number of the message 695 that was sent by the node which generated the packet. This is 696 incremented monolithically for each message generated by a node. 698 o Message Type - The message type value of the message through 699 which the table row was populated. 701 8. CML Timers 703 8.1. Oscillation timer 705 The Oscillation timer is used in the o-phase to prevent phase shifts 706 within the time period of "Osc_Interval". This timer prevents phase 707 shift due to frequent oscillations. 709 9. Constants 711 9.1. Network Threshold Values 713 The Network threshold values for CML are described below: 715 o NST - The theoretical Network size threshold "Nt" of a network 716 depends on the number of nodes N in the network, the critical 717 area A of the network and the radio coverage area of each node. 718 NST marks the point after which a reactive routing approach will 719 be more effective (in terms of end to end packet delivery 720 latency) and efficient (in terms of battery usage) compared to a 721 reactive routing approach. Below the NST point, proactive routing 722 approaches outperform reactive routing approaches. 724 o U-NST - The Upper limit network size threshold "Nu" is given by: 726 Nu = Nt + Nosc 728 where "Nosc" is the number of nodes in the network which are 729 expected to oscillate. 731 When operating in the p-phase the actual value of NST is equal to 732 "Nu". 734 o L-NST - The Lower limit network size threshold "Nl" is given by: 736 Nl = Nt - Nosc 738 When operating in the r-phase the actual value of NST is equal to 739 "Nl". 741 o NHT - The network hop threshold value "Nht" is directly 742 proportional to the square root value of the NST: 744 Nht = Function (sqrt (Nt)) 746 The optimal values for "Nt", "Nosc", "Nu", "Nl" and "Nht" as well as an 747 accurate relationship between NST and NHT can be derived through 748 experimentation and mathematical modeling for a given critical area, 749 'A' and node coverage radius 'R'. 751 9.2. Oscillation Interval (Osc_Interval) 753 The Osc_Interval is a time period for which no phase shift is 754 allowed. While the U-NST and L-NST values cater for group 755 oscillations, the Osc_Interval prevents unnecessary phase shift 756 overheads due to regular oscillations. Thus, the Osc_Interval SHOULD 757 be set according to the time period of node oscillations. The 758 optimal value for Osc_Interval can be derived through 759 experimentation and mathematical modeling for a given critical area, 760 'A' and node coverage radius 'R'. 762 9.3. Parameter Values 764 Parameter values used by the CML protocol and also defined in [3] 765 and [6] are: 767 Parameter Name Value 768 ---------------------- ----- 769 NET_DIAMETER 35 770 NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER 771 NODE_TRAVERSAL_TIME 40 milliseconds 772 PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME 773 HELLO_INTERVAL 2 seconds 774 TC_INTERVAL 5 seconds 776 10. Message Emission and Jitter 778 Synchronization of control messages SHOULD be avoided as mentioned 779 in [2]. 781 11. IPv6 Considerations 783 All the operations and parameters described in this document can be 784 used for both IP version 4 and IP version 6. For IPv6 networks, the 785 IPv4 addresses in CML packets and messages need to be replaced by 786 IPv6 addresses. The packet and message sizes will also increase 787 accordingly. 789 12. Security Considerations 791 CML does not specify any special security countermeasures. Although, 792 different secure versions of AODV and OLSR have been proposed in the 793 literature [12], CML introduces new vulnerabilities. Firstly, any 794 malicious node can generate a change phase packet to call the o- 795 phase of CML and the routing behaviors will accordingly change. In 796 this way, CML will not operate in the proper routing mode and the 797 MANET's performance will not be optimal considering the real number 798 of nodes in the network. Apart from that, legitimate nodes will 799 flood the network with the CML CP packet generating traffic overhead 800 within the MANET. Furthermore, a set of malicious nodes that 801 coordinate their actions against the CML may periodically come into 802 and depart from the network. In this way, CML recognizes that the 803 number of nodes in the MANET has changed and oscillates from the 804 proactive phase to the reactive or vice-versa. The continuous 805 oscillation of CML can result in draining the battery level of the 806 emergency devices rapidly. Another version of the above attack is 807 launched when malicious nodes change the "hop value" in the CML 808 HCReq Packet. In this case, legitimate nodes believe that the size 809 of the network has changed and CML oscillates unreasonably. On the 810 other hand, if a phase shift should take place (due to a real change 811 of the number of nodes) but malicious nodes succeed to drop some or 812 all of the Change Phase packets the performance of MANET will not be 813 optimized. Therefore, security intelligent approaches have to be 814 integrated into CML to avoid the aforementioned attacks and to 815 provide eMANET nodes with basic security requirements such as 816 confidentiality, authentication, integrity and availability. 818 13. IANA Considerations 820 The IANA consideration section is required as recommended by [7] and 821 [9]. The following values for the corresponding message types would 822 be required: 824 Message Type Value 825 -------------------- ----- 827 HELLO_MESSAGE = 1 828 TC_MESSAGE = 2 830 MID_MESSAGE = 3 832 HNA_MESSAGE = 4 834 ROUTE REQUEST (RREQ) = 5 836 ROUTE REPLY (RREP) = 6 838 ROUTE ERROR (RERR) = 7 840 ROUTE-REPLY ACK (RREP-ACK)= 8 842 HOP COUNT REQUEST (HCREQ) = 9 844 HOP COUNT REPLY (HCREP) = 10 846 CHANGE PHASE (CP) = 11 848 14. Conclusions 850 This I-D introduced the CML routing protocol. In extreme emergency 851 situations, rescuers tend to join and/or leave the network 852 frequently, thus changing network size. CML is a hybrid protocol 853 which combines the functionalities of OLSR and AODV protocols in an 854 adaptive manner. The motivation behind CML is the enhancement of the 855 overall routing performance for varying size networks. The main 856 features of CML include the Adaptive Module, which monitors and 857 adapts to the changing network state, and the o-phase which 858 considers the case of node oscillation. Future CML versions will 859 augment the Adaptive module and make CML adaptive to additional 860 MANET contexts. 862 Furthermore, more security aspects of CML will be discussed towards 863 the provision of security against adversaries that try to launch 864 different types of network layer attacks. 866 15. References 868 15.1. Normative References 870 [1] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [2] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 874 considerations in MANETs", RFC 5148, February 2008. 876 [3] Perkins, C., Belding-Royer, E., and Das S., "Ad hoc On-Demand 877 Distance Vector (AODV) Routing", RFC 3561, July 2003. 879 [4] Ramrekha, T., Emmanouil, E., and Politis, C., "A Generic 880 Cognitive Adaptive Module (CAM) for MANETs", draft-ramrekha- 881 manet-cam-00, June 2010. 883 [5] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): 884 Routing Protocol Performance Issues and Evaluation 885 Considerations", RFC 2501, January 1999. 887 [6] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 888 Protocol", RFC 3626, October 2003. 890 15.2. Informative References 892 [7] PEACE team, "First draft of the emergency framework" PEACE, 893 ICT-SEC-2007.1.7, Deliverable 2.2 (Public), June 2009. 895 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 896 Considerations Section in RFCs", RFC 5226, BCP 26, May 2008. 898 [9] Clausen, T., Dean, J., Dearlove, C., and Adjih, C. 899 "Generalized MANET Packet/Message Format", RFC 5444, February 900 2009. 902 [10] Chakeres, I., "IANA Allocations for MANET Protocols", RFC 903 5498, March 2009. 905 [11] Clausen, T. and C. Dearlove, "Representing multi-value time in 906 MANETs", RFC 5497, March 2009. 908 [12] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc 909 Networks", ISBN: 978-0-471-75688-0, John Wiley & Sons, March 910 2007. 912 16. Acknowledgments 914 The authors wish to acknowledge the support of the ICT European 7th 915 Framework Program and all the partners in PEACE (IP-based Emergency 916 Applications and services for next generation networks) project with 917 contract number 225654. 919 This document was prepared using 2-Word-v2.0.template.dot. 921 Authors' Addresses 923 The following researchers who have contributed to this I-D are 924 members of the Wireless Multimedia and Networking (WMN) Research 925 Group at Kingston University London: 927 Tipu Arvind Ramrekha 928 Researcher, WMN Research Group 929 Kingston University London 930 UK KT1 2EE 932 Phone: (+44) 02084177025 933 Email: a.ramrekha@kingston.ac.uk 935 Emmanouil A. Panaousis 936 Researcher, WMN Research Group 937 Kingston University London 938 UK KT1 2EE 940 Phone: (+44) 02084177025 941 Email: e.panaousis@kingston.ac.uk 943 Christos Politis 944 Head of WMN Research Group 945 Kingston University London 946 UK KT1 2EE 948 Phone: (+44) 02084172653 949 Email: c.politis@kingston.ac.uk