Internet DRAFT - draft-ladas-manet-cmlv2
draft-ladas-manet-cmlv2
Network Working Group A.Ladas
Internet-Draft N.Weerasinghe
Intended status: Experimental C.Politis
Expires: March 12, 2016 O.Adigun
WMN Research Group
Kingston University London
O. Adigun
UbiTech Ltd
September 08,2015
ChaMeLeon Version 2 (CMLv2): A multipath hybrid routing protocol
draft-ladas-manet-cmlv2-01.txt
Abstract
This document describes the ChaMeLeon Version 2 (CMLv2) routing protocol
designed for Mobile Ad hoc Networks (MANETs). CMLv2 is a multi-path,
hybrid routing protocol operating within a defined area denoted as the
Critical Area (CA). The main concept behind CMLv2 is the adaptability of
its routing mechanisms towards changes in the physical and logical state
of a MANET. For autonomous communications, there is a likelihood
that the network size will vary whenever more devices join or leave the
network. In addition, battery depletion of lightweight mobile
communication devices will stipulate another reason for changes in the
network size. Hence, CMLv2 adapts its routing behavior according to
changes in the network size within a pre-defined CA. For small networks,
CMLv2 routes data proactively using the Optimized Link State Routing
version v2 (OLSRv2) protocol whereas for larger networks it utilizes the
reactive Ad hoc On-Demand Distance Vector Version 2 (AODVv2) Routing
protocol. These transitions occur via the oscillation phase, which is
maintained from CMLv1. O-phase will be totally removed in the next
release of CMLv2.CMLv2 creates multi-path routes for nodes with disjoint
paths thereby increasing the reliability of the network.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2016.
Ladas et al. Expires March 12, 2016 [Page 1]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 3
2.1. CML Terminology......................................... 3
3. Applicability ............................................... 3
4. Protocol Overview ........................................... 4
4.1. Monitor Component....................................... 4
4.2. Adaptive Component...................................... 5
4.3. O-phase ................................................ 6
5. Protocol Operation .......................................... 7
5.1. P-phase ................................................ 7
5.2. R-phase ................................................ 8
5.3. O-phase ................................................ 8
5.3.1. Operation ......................................... 8
6. CML Packet and Message Formats............................... 9
6.1. Packet Format .......................................... 9
6.2. Change Phase (CP) Message............................... 9
6.3. Hop Count Request (HCReq) Message....................... 9
6.4. Hop Count Request (HCRep) Message...................... 10
7. CML tables ................................................. 10
7.1. CML Change Phase table................................. 10
8. CML Timers ................................................. 10
8.1. Oscillation timer...................................... 10
9. Constants .................................................. 10
9.1. Network Threshold Values............................... 10
9.2. Oscillation Interval (Osc_Interval).................... 11
9.3. Parameter Values....................................... 11
10. Message Emission and Jitter................................. 12
11. IPv6 Considerations......................................... 12
12. Security Considerations..................................... 12
13. IANA Considerations......................................... 12
14. Conclusions ................................................ 13
15. References ................................................. 13
15.1. Normative References.................................. 13
15.2. Informative References................................ 13
16. Acknowledgments ............................................ 14
Ladas et al. Expires March 12, 2016 [Page 2]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
1. Introduction
This protocol is a multipath hybrid routing protocol for MANETs
It consists of 3 phases of operation namely Proactive, Oscillation and
Reactive. The Proactive (p-) and Reactive (r-) phases operate in the
same way as the core functions of [3] and [6] respectively and are discrete
from each other. This draft focuses on the optimization of the p-phase by
proposing a new route computation approach compared with [4] for multipath
operation. By applying this multipath approach, our main aim is to ensure
load balancing, improve QoS and delay, provide reliable communication among
the nodes and maximize network life. In this draft, the r-phase of CMLv2 is
not multipath, it is simply an on-demand route computation. CMLv2 makes no
assumptions about the underlying link layer.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
2.1. CMLv2 Terminology
This section defines terminology associated with CMLv2 that is not
already defined in or that differs from the meaning of the
terminology in [11], [6] [8]and [3].
o The p-phase is based on MP-OLSRv2 Routing Process - The routing
process is based on the specification [6], [4]
o Proactive Route Computation Terminology - The route computation process
that is going to be used in CMLv2 is based on an Advanced Relay Routing
(ARR) approach.
o The r-phase remains the same as defined in AODVv2 [3]
3. Applicability
The design of CMLv2 has been constructed to provide robust and efficient
communication for wireless networks, by exploiting the multi-path
information transfer and hybridity of the two approaches. The autonomous
nature of MANETs is very suitable for a variety of scenarios, especially
when multiple dis-joint paths exist within the CA . Also, in such a
context, the number of MANET nodes varies depending on different
parameters.
. Battery limitation of nodes is a very important consideration.
Node failure as a consequence of battery depletion MAY result
in network segmentation.
. Nodes MAY join or leave the network anytime.
. A certain quality of service (QoS) level has to be maintained
to allow for multimedia communication. Mainly, certain delay
bounds have to be established while also maintaining effective
routing by minimizing battery consumption.
Ladas et al. Expires March 12, 2016 [Page 3]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
CMLv2 has the ability to adapt its routing behavior to changes in
MANET size. Hence, it is a more suitable routing alternative than
pure routing approaches for small, large as well as variable sized
MANETs operating in a defined CA. Future versions of CMLv2 will
consider high level of mobility support, so as to be applicable in
very dynamic topology networks.
4. Protocol Overview
This protocol is designed to work as a multi-path, hybrid and adaptive
Routing protocol for MANETs. The normal mode of operation is under one of
the stable phases. The default operating phase is the p-phase. This
section describes the various processes and structures introduced
by CMLv2.
4.1 Monitor Component
When a control message is received, the node MUST:
1. Send a copy of the packet to the monitor part of the module.
The monitor component has a network size part that MUST check
the number of nodes in the network. This is accomplished
differently depending on the current stable phase of operation
(as described later).
2. Send the packet to the regular control message processing
by the stable phase, as described in [3] or section 5.1.
The current active routing part.
The monitor part determines the network size as follows. In the p-
phase (where the OLSRv2 routing algorithm is active), this task
consists of calculating the number of reachable hosts from the
routing table as defined in [6]. This calculation is done by
counting the number of rows in the proactive routing table. Each row
includes fields of possible destination nodes, the next hop to
reach the destination as specified in the possible destination field
and its distance from the current source node. These field values
are computed using periodical Topology Control (TC) and HELLO
message broadcasts by each node in the network. If the number of
nodes is found to exceed the NST, this monitor part must contact the
L-NST part of the Adaptive Component.
In the r-phase (where the AODVv2 routing algorithm is active), the
number of nodes in the network is estimated using the maximum value
of the hop count from a source node to a destination. As defined in
[3], a source finds a route to a destination 'on-demand' by flooding
a Route Request (RReq) packet throughout the network using an
expanding ring approach until a RRep is received from the
destination.
Ladas et al. Expires March 12, 2016 [Page 4]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
The monitor function in the source node must use this RRep message to
obtain the value of Hop Count (HC) towards the destination node. It then
compares this with the U-NST, which is calculated according to the
relationship defined in section 9.1. The monitor function MUST act as
follows:
1. If HC in RRep is greater or equal to U-NST, it decides that the
NST is not exceeded.
2. If HC in RRep is less than the U-NST, the data packets are
transmitted through the established route. After data
transmission, the CMLv2 Hop Count Request (HCReq) packet described
in section 6.3. MUST be generated and flooded in the network to
probe for the network HC (as opposed to destination HC). The HC
is said to be less than the NHT, if after RREQ_WAIT_TIME
* DISCOVERY_ATTEMPTS_MAX, no HCRep has been received.
If the HC is less than the U-NST, the monitor function decides
that the r-phase NST (calculated using the relationship
in section 9.1.), has been exceeded and calls the U-NST part
of the Adaptive component.
If a node receives HCReq, it must first make sure that the sequence
number of the packet is greater than that stored in the Change Phase
(CP) table for the same originator address. Then, it checks if the
TTL = 0. If the latter is true, it MUST store HCReq originator IP
and packet sequence number information in the CP table and send back
an HCRep to the originator, as described in section 6.4. Otherwise,
it decreases the TTL value and floods back the HCReq packet in the
network. It then generates and floods its own HCReq to probe for the
HC with TTL value set to NHT. The value of the originator address of
the original HCReq packet (triggering the probing locally) is stored
in the CP table along with the sequence number.
The message type field is set equal to the value of message type "
HCReq" as which is equal to '9' as mentioned in section 13.
If for that particular HCReq, an HCRep is received, the node must
send an additional HCRep to that HCReq originator address.
If a node receives a CMLv2 CP Packet described in section 6.2. , it
MUST flood the packet in the network after decreasing its TTL count.
Then, the active routing algorithm part of the node MUST call the
relevant Adaptive part from its Adaptive component.
4.2. Adaptive Component
The Adaptive component, when called by the monitor (in case
a CP packet is received) component MUST be sure of the following:
1. The Adaptive part ID used in the calling message is valid.
2. The Adaptive part ID corresponds to the appropriate part with
respect to the active routing component if contacted from the
monitor part as described in the above section.
Ladas et al. Expires March 12, 2016 [Page 5]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
3. In the case where the CP packet requires that an inappropriate
(see point 2 above) Adaptive part be contacted, this action is
ignored and the CP is flooded back in the network.
Any of the activated Adaptive part, subsequent to the above steps,
MUST change operation to o-phase as it is explained in section 4.3.
In any other situation, the Adapt function terminates and the
appropriate stable phase operation is resumed.
4.3. O-phase
In the o-phase, the Adaptive component checks the o-phase validity
time, "Osc_Interval" of the oscillation timer described in section
8.1. , is first checked. If the timer is still valid, the o-phase
variable in the core is cleared and consequently the stable phase of
operation is maintained. If the timer has expired, the o-phase
variable is set and:
1. If the routing algorithm ID (RID) is set to OLSRv2:
The OLSRv2 mechanism will continue to operate. At the same time,
the node will check the number of nodes in the network as
described in section 4. for 2 * TC_Intervals (TC_Interval is
described in [6]). If the number of nodes is then found to be
greater than L-NST at least once, the o-phase switches to r-phase
and resets the oscillation timer. It also generates and floods a
CMLv2 CP Packet. The CP packet includes its address as originator
address and its incremented sequence number. The CP field value
of the CMLv2 packet is set as "AODVv2 RID".
Otherwise, the node returns to operating in the p-phase.
2. If the routing algorithm ID (RID) is set to AODVv2:
The routing mechanism of AODVv2 will continue to operate. At the
same time, the Monitor and Adaptive component will check the HC
of the network using two more HCReq packets, as described in
section 6.3. , waiting for RREQ_WAIT_TIME * DISCOVERY_ATTEMPTS_MAX
(RREQ_WAIT_TIME and DISCOVERY_ATTEMPTS_MAX are explained in [3])
each time. If in at least one occurrence, no HCRep is obtained
for the HCReq with TTL=U-NHT, it is implied that the network size is
smaller than the NST. In this case, the o-phase switches to p-phase by
clearing the o-phase variable and setting the RID to the OLSRv2
RID. The oscillation timer is also reset. It also generates and
floods a CMLv2 CP packet. The CP packet includes its address as
originator address and its incremented sequence number. The value
of the CP field in the packet is set to "OLSRv2 RID".
Otherwise, stable r-phase routing is resumed.
3. If this phase shift is initiated using a CMLv2 CP packet:
Ladas et al. Expires March 12, 2016 [Page 6]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
The node core MUST check the value of the sequence number in the
packet and compare it to any stored sequence number having the
same originator address in the CP table. If no match is found in
the CP table, a new entry is created with the aforementioned
values obtained from the CP packet before further processing.
Otherwise, if a match is found and the packet sequence number is
less than the sequence number stored in the table, the message is
silently discarded and the node returns to the stable phase
specified by its core RID variable.
For non-discarded packets, the node MUST check the CP field value in
the CP packets and compare it with its own RID:
1. If they are equal, the CP packet is silently discarded and the
node returns to the phase specified by its core RID.
2. If they are not equal, the o-phase changes the RID to the value
specified in the CP field of the CP message and resets the
oscillation timer.
In both cases, the CP packets are flooded back in the network.
5. Protocol Operation
This section describes the behavior CMLv2 MUST follow in the p-phase,
r-phase and o-phase.
5.1. P-phase
In the p-phase, the node core receives packets with all message
types but only processes packets with message types [1-2] and routes
data packets as described in [8]. It also processes packets with
message types 9-11 as described in this draft. In addition, it
sends a copy of the packet to the Monitor component each time a TC
routing packet is received.
In this phase, NST is equal to U-NST to cater for group oscillation.
The proactive phase of CMLv2 is based on [6][4] but the route is computed
differently. According to [4] when a packet has to be forwarded from
the source to the destination, the source node acquires a path from
the Multi-path Routing Set, storing the path information in the
datagram header as source routing header. Each of the intermediate
nodes, is listed in the source routing header and it forwards the
packet to the next hop as indicated in the source routing header.
In our approach, each node, upon receiving a packet, computes all the
dis-joint paths to the destination node. The next step is to check if
it is on the best (or 2nd, or 3rd, and so on, best) path to the final
destination. If this is valid, the packet is forwarded. Considering this
method, the multi-path Dijkstra algorithm will be employed for finding
the best route.
Ladas et al. Expires March 12, 2016 [Page 7]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
The routing decision for determining the best path will be
taken by using the Expected Transmission Count ETX) [7] metric. If
the number of paths is higher than 3, then the 3 best routes are
selected according to the ETX metric. So, regarding this approach
the decision of which path(s) is going to be selected is taken
according to the ETX metric instead of using the hop count metric.
5.2. R-phase
In the r-phase, the node core receives packets with all message
types but processes only packets with message types 5-8 and routes
data packets as specified in [3]. It also processes packets with
message types 9-11 as described in this document. In addition, it
sends a copy of the packet to the Monitor component each time it
receives RRep routing packets as a source node.
In this phase, NST is equal to L-NST to cater for group oscillation.
5.3. O-phase
In this subsection we describe the oscillation problem and the
operation of the o-phase as a mechanism to counteract oscillation
effects in MANETs that use the CMLv2 protocol.
The basic operations of the current stable phase still apply in the
o-phase. However, there are added phase dependent sampling processes
to check for oscillation instances. O-phase will be totally removed
in the next release of CMLv2.
5.3.1. Operation
CMLv2 proposes a twofold solution to the oscillation problem.
Appropriate NSL values (acting as NST) can restrain the effects of
group oscillations whereas the right "Osc_Interval" value for the
oscillation timer limits the impact of frequent oscillations.
In addition, during the o-phase, the monitor component samples more
instances of the 'number of nodes' count or the network HC
(depending on the current stable phase of operation) as described in
section 4. In this way, it can confirm whether the NST or NHT has
actually been exceeded. Otherwise, it determines that an oscillation
has occurred and the stable phase of operation is resumed. If the
NST is found to have been actually exceeded in the o-phase, the
appropriate part of the Adaptive component (identified as explained
above) resets the oscillation timer and generates CP packets. These
CP packets are flooded into the network to alert neighboring nodes
of such a phase shift. The o-phase is then terminated by the
Adaptive Component part that then shifts routing operation to the
relevant stable phase of operation.
Furthermore, during the o-phase, the core and active Adaptive
component part are responsible for phase shifting if a valid CP
packet is received from a neighboring node (as explained above). In
such a case, it floods back the CP packet in the network.
Ladas et al. Expires March 12, 2016 [Page 8]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
Furthermore, during the o-phase, the core and active Adaptive
component part are responsible for phase shifting if a valid
CP packet is received from a neighboring node (as explained above).
In such a case, it floods back the CP packet in the network. If the
protocol phase changes from P-phase to R-phase, and a HELLO packet
is received, the information about next hop is stored in the routing
table. A TC packet information is used to either reset a timeout in
the routing table or populate routing table information for potential
data to be sent. In the case where the transition occurs from the
R-phase to the P-phase, and RREQ are requested, if the destination is
already in the routing table, a RREP is sent back with this information.
Otherwise, the RREQ is stored until 2 *TC_INTERVAL before sending a RREP.
6. CMLv2 Packet and Message Formats
6.1. Packet Format
The basic layout of a CMLv2 packet is as recommended in [11]. The
message type field indicates the type of message found in the
"MESSAGE" section.
This could be a CMLv2 message or messages from [6] or [3] or the CP message.
6.2. Change Phase (CP) Message
The Change Phase message format is shown below:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CP containing RID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Change Phase (CP) - The CP field contains the RID to which the
originator node has shifted to and subsequently requests neighbor
nodes to shift to.
6.3. Hop Count Request (HCReq) Message
The HCReq message has an empty message body. It can be identified as
a CML packet with:
o Message Type - The value of message type is set to 9.
o TTL - The TTL value is set to NHT.
Ladas et al. Expires March 12, 2016 [Page 9]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
6.4. Hop Count Request (HCRep) Message
The message format for the HCRep message is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Destination IP address - Originator IP address in corresponding
HCReq packet.
o Destination Sequence Number - Originator Sequence Number of
corresponding HCReq packet.
7. CMLv2 tables
7.1. CMLv2 Change Phase table
The CMLv2 CP Table fields are listed below:
o Originator IP Address - The IP address of the node which
generated the packet.
o Originator Sequence Number - The Sequence number of the message
that was sent by the node which generated the packet. This is
incremented monolithically for each message generated by a node.
o Message Type - The message type value of the message through
which the table row was populated.
8. CMLv2 Timers
8.1. Oscillation timer
The Oscillation timer is used in the o-phase to prevent phase shifts
within the time period of "Osc_Interval". This timer prevents phase
shift due to frequent oscillations.
9. Constants
9.1. Network Threshold Values
The Network threshold values for CMLv2 are described below:
o NST - The theoretical Network size threshold "Nt" of a network
depends on the number of nodes N in the network, the critical
area A of the network and the radio coverage area of each node.
NST marks the point after which a reactive routing approach will
be more effective (in terms of end to end packet delivery
latency) and efficient (in terms of battery usage) compared to a
reactive routing approach.
Ladas et al. Expires March 12, 2016 [Page 10]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
Below the NST point, proactive routing approaches outperform
reactive routing approaches.
o U-NST - The Upper limit network size threshold "Nu" is given by:
Nu = Nt + Nosc
where "Nosc" is the number of nodes in the network which are
expected to oscillate.
When operating in the p-phase the actual value of NST is equal to
"Nu".
o L-NST - The Lower limit network size threshold "Nl" is given by:
Nl = Nt - Nosc
When operating in the r-phase the actual value of NST is equal to
"Nl".
o NHT - The network hop threshold value "Nht" is directly
proportional to the square root value of the NST:
Nht = Function (sqrt (Nt))
The optimal values for "Nt", "Nosc", "Nu", "Nl" and "Nht" as well as an
accurate relationship between NST and NHT can be derived through
experimentation and mathematical modeling for a given critical area,
'A' and node coverage radius 'R'.
9.2. Oscillation Interval (Osc_Interval)
The Osc_Interval is a time period for which no phase shift is
allowed. While the U-NST and L-NST values cater for group
oscillations, the Osc_Interval prevents unnecessary phase shift
overheads due to regular oscillations. Thus, the Osc_Interval SHOULD
be set according to the time period of node oscillations. The
optimal value for Osc_Interval can be derived through
experimentation and mathematical modeling for a given critical area,
'A' and node coverage radius 'R'.
9.3. Parameter Values
Parameter values used by the CMLv2 protocol and also defined in [3]
and [6] are:
Parameter Name Value
---------------------- -----
RREQ_WAIT_TIME 2 seconds
DISCOVERY_ATTEMPTS_MAX 3 attempts
RREQ_HOLDDOWN_TIME 10 seconds
HELLO_INTERVAL 2 seconds
TC_INTERVAL 5 seconds
Ladas et al. Expires March 12, 2016 [Page 11]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
10. Message Emission and Jitter
Synchronization of control messages SHOULD be avoided as mentioned
in [2].
11. IPv6 Considerations
All the operations and parameters described in this document can be
used for both IP version 4 and IP version 6. For IPv6 networks, the
IPv4 addresses in CMLv2 packets and messages need to be replaced by
IPv6 addresses. The packet and message sizes will also increase
accordingly.
12. Security Considerations
CMLv2 does not specify any security countermeasures. Security
Threats for OLSRv2 are described in IETF draft ?Security Threats for
the Optimized Link State Routing Protocol Version 2 (OLSRv2)?[9]
and for the ?Ad-Hoc On-demand Distance Vector Version 2 (AODVv2)
[3] which are applicable to CMLv2.
CMLv2 Packet/Message Format follow the Generalized Mobile Ad Hoc Network
(MANET) Packet/Message Format proposed in [11]. Hence the security
mechanisms suggested in [11] and [14] can be directly applied to this
protocol. The network performance can also be affected by artificial
manipulation of metric values. More specific, if a link is, artificially,
advertised with a higher value, the amount of incoming traffic may be
reduced. A malicious node, might decrease or increase the value of the
advertised links, in order to increase or decrease the data traffic.
Thus, a malicious node can potentially affect data throughput, by not
sending data from good links and vice versa.
13. IANA Considerations
The IANA consideration section is required as recommended by [10] and
[12]. The following values for the corresponding message types would
be required:
Message Type Value
-------------------- -----
HELLO_MESSAGE = 1
TC_MESSAGE = 2
ROUTE REQUEST (RREQ) = 3
ROUTE REPLY (RREP) = 4
ROUTE ERROR (RERR) = 5
ROUTE-REPLY ACK (RREP-ACK)= 6
HOP COUNT REQUEST (HCREQ) = 7
Ladas et al. Expires March 12, 2016 [Page 12]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
HOP COUNT REPLY (HCREP) = 8
CHANGE PHASE (CP) = 9
14. Conclusions
This I-D introduced the CMLv2 routing protocol. CMLv2 is a routing protocol
which combines the functionalities of Multi-path OLSRv2 and AODVv2
protocols in an adaptive and hybrid manner. The motivation behind CMLv2 is
the enhancement and the increase of the reliability and robustness of the
networks. The main features of CMLv2 include the Adaptive Module, which
monitors and adapts to the changing network state, the p-phase which
computes multiple routes according to the link quality metric (ETX),
the r-phase which is computes multiple routes in an on-demand manner. In the
next release, CMLv2 will be enchanced by removing the o-phase and will operate
as a single protocol.Furthermore, CMLv2 will consider ways to improve the mobility
support.
15. References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", RFC 5148, March 2008.
[3] Perkins, et al., "Dynamic MANET On-demand (AODVv2)
Routing", IETF Draft, December 2014.
[4] Yi,J. and Parrein,B., "Multi-path Extension for the
Optimized Link State Routing Protocol version 2 (OLSRv2) ",
IETF Draft, October 2014.
[5] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999.
[6] Clausen, T., Dearlove, C., Jacquet, P., Herberg, U.,
"The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014.
[7] Vasseur, JP., Kim, M., Pister, K., Dejean, N., Barthel, D.,
"Routing Metrics Used for Path Calculation in Low ?
Power and Lossy Networks", RFC 6551, March 2012.
[8] Ramrekha, A., Panaousis, E., Politis, C., "ChaMeLeon (CML):
A hybrid and adaptive routing protocol for Emergency
Situations", IETF Draft March 2011.
Ladas et al. Expires March 12, 2016 [Page 13]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
15.2. Informative References
[9] Clausen, T., Herberg, U., Yi, J., "Security Threats for the
Optimized Link State Routing Protocol version 2 (OLSRv2) ",
IETF Draft, August 2014.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, BCP 26, May 2008.
[11] Clausen, T., Dean, J., Dearlove, C., and Adjih, C.
"Generalized MANET Packet/Message Format", RFC 5444, March 2009.
[12] Chakeres, I., "IANA Allocations for MANET Protocols", RFC
5498, March 2009.
[13] Clausen, T. and C. Dearlove, "Representing multi-value time in
MANETs", RFC 5497, March 2009.
[14] Herberg, U., Dearlove, C., Clausen, T., "Integrity Protection for the
Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing
Protocol Version 2 (OLSRv2)", RFC 7183, April 2014.
16. Acknowledgments
The authors wish to acknowledge the support of the ICT European 7th
Framework Program and all the partners in SALUS (Security And
InteroperabiLity in Next Generation PPDR CommUnication InfrastructureS)
project with contract number 313296 and also the support of the ICT
European 7th Framework Program and all partners in PROACTIVE
PRedictive reasOning and multi-source fusion empowering AntiCipation of
attacks and Terrorist actions In Urban EnVironmEnts with contract number
285320.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
The following researchers who have contributed to this I-D are
members of the Wireless Multimedia and Networking (WMN) Research
Group at Kingston University London:
Alexandros D. Ladas
Researcher
Researcher, WMN Research Group
Kingston University London
UK KT1 2EE
Phone: (+44) 02084177025
Email: a.ladas@kingston.ac.uk
Nuwan Weerasinghe
Researcher, WMN Research Group
Kingston University London
UK KT1 2EE
Phone: (+44) 02084177025
Email: nuwan.weerasinghe@kingston.ac.uk
Ladas et al. Expires March 12, 2016 [Page 14]
Internet-Draft ChaMeLeon Version 2 (CMLv2) September 2015
Christos Politis
Head of WMN Research Group
Kingston University London
UK KT1 2EE
Phone: (+44) 02084172653
Email: c.politis@kingston.ac.uk
Olayinka Adigun
Researcher, WMN Research Group
Kingston University London
UK KT1 2EE
Phone: (+44) 02084177025
Email: o.adigun@kingston.ac.uk
Olayinka Adigun
Technical Manager
UbiTech Ltd
UK GU2 7YG
Phone: (+44) 01483685308
Email: olayinka@ubitechit.com
Ladas et al. Expires March 12, 2016 [Page 15]
