draft-ietf-manet-olsrv2-metrics-rationale-03.txt   draft-ietf-manet-olsrv2-metrics-rationale-04.txt 
Mobile Ad hoc Networking (MANET) C. Dearlove Mobile Ad hoc Networking (MANET) C. Dearlove
Internet-Draft BAE Systems ATC Internet-Draft BAE Systems ATC
Intended status: Informational T. Clausen Intended status: Informational T. Clausen
Expires: October 11, 2013 LIX, Ecole Polytechnique Expires: November 2, 2013 LIX, Ecole Polytechnique
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
April 9, 2013 May 1, 2013
Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol
OLSRv2 - Rationale OLSRv2 - Rationale
draft-ietf-manet-olsrv2-metrics-rationale-03 draft-ietf-manet-olsrv2-metrics-rationale-04
Abstract Abstract
OLSRv2 includes the ability to assign metrics to links and to use OLSRv2 includes the ability to assign metrics to links and to use
those metrics to allow routing by other than minimum hop count those metrics to allow routing by other than minimum hop count
routes. This document provides a historic record of the rationale routes. This document provides a historic record of the rationale
for, and design considerations behind, how link metrics were included for, and design considerations behind, how link metrics were included
in OLSRv2. in OLSRv2.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2013. This Internet-Draft will expire on November 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Motivational Scenarios . . . . . . . . . . . . . . . . . . . . 7 4. Motivational Scenarios . . . . . . . . . . . . . . . . . . . . 8
5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Link Metric Properties . . . . . . . . . . . . . . . . . . 9 5.1. Link Metric Properties . . . . . . . . . . . . . . . . . . 10
5.2. Link Metric Types . . . . . . . . . . . . . . . . . . . . 10 5.2. Link Metric Types . . . . . . . . . . . . . . . . . . . . 11
5.3. Directional Link Metrics . . . . . . . . . . . . . . . . . 11 5.3. Directional Link Metrics . . . . . . . . . . . . . . . . . 12
5.4. Reporting Link and Neighbor Metrics . . . . . . . . . . . 12 5.4. Reporting Link and Neighbor Metrics . . . . . . . . . . . 13
5.5. Defining Incoming Link Metrics . . . . . . . . . . . . . . 13 5.5. Defining Incoming Link Metrics . . . . . . . . . . . . . . 14
5.6. Link Metric Values . . . . . . . . . . . . . . . . . . . . 14 5.6. Link Metric Values . . . . . . . . . . . . . . . . . . . . 15
6. MPRs with Link Metrics . . . . . . . . . . . . . . . . . . . . 16 6. MPRs with Link Metrics . . . . . . . . . . . . . . . . . . . . 17
6.1. Flooding MPRs . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Flooding MPRs . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Routing MPRs . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Routing MPRs . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Relationship Between MPR Sets . . . . . . . . . . . . . . 21 6.3. Relationship Between MPR Sets . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10. Informative References . . . . . . . . . . . . . . . . . . . . 26 10. Informative References . . . . . . . . . . . . . . . . . . . . 27
Appendix A. MPR Routing Property . . . . . . . . . . . . . . . . 27 Appendix A. MPR Routing Property . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol version 1 (OLSRv1) The Optimized Link State Routing Protocol version 1 (OLSRv1)
[RFC3626] is a proactive routing protocol for Mobile Ad hoc NETworks [RFC3626] is a proactive routing protocol for Mobile Ad hoc NETworks
(MANETs) [RFC2501]. OLSRv1 finds shortest, defined as minimum number (MANETs) [RFC2501]. OLSRv1 finds shortest, defined as minimum number
of hops, routes from a router to all possible destinations. of hops, routes from a router to all possible destinations.
Using only minimum hop routes may result in what are, in practice, Using only minimum hop routes may result in what are, in practice,
inferior routes. Some examples are given in Section 4. Thus, one of inferior routes. Some examples are given in Section 4. Thus, one of
skipping to change at page 3, line 42 skipping to change at page 3, line 42
metric. Using a definition of route metric other than number of hops metric. Using a definition of route metric other than number of hops
is a natural extension that is commonly used in link state protocols. is a natural extension that is commonly used in link state protocols.
Use of the extensible message format [RFC5444] by OLSRv2 has allowed Use of the extensible message format [RFC5444] by OLSRv2 has allowed
the addition, by OLSRv2, of link metric information to the HELLO the addition, by OLSRv2, of link metric information to the HELLO
messages defined in the MANET NeighborHood Discovery Protocol (NHDP) messages defined in the MANET NeighborHood Discovery Protocol (NHDP)
[RFC6130] as well as inclusion in the Topology Control (TC) messages [RFC6130] as well as inclusion in the Topology Control (TC) messages
defined in [OLSRv2]. defined in [OLSRv2].
A metric-based route selection processes for OLSRv2 could have been A metric-based route selection processes for OLSRv2 could have been
handled as an extension to OLSRv2. However in this case, legacy handled as an extension to OLSRv2. However were this to have been
OLSRv2 routers, which would not recognize any link metric done, OLSRv2 routers that did not implement this extension would not
information, would still attempt to use minimum hop-count routes. recognize any link metric information, and would attempt to use
This would mean that, in effect, routers differed over their minimum hop-count routes. This would have meant that, in effect,
valuation of links and routes. This would have led to the routers that did and did not implement this extension would differ
over their valuation of links and routes. This would have led to the
fundamental routing problem of "looping". Thus if metric-based route fundamental routing problem of "looping". Thus if metric-based route
selection were to have been considered only as an extension to selection were to have been considered only as an extension to
OLSRv2, then routers which did, and routers which did not, implement OLSRv2, then routers that did, and routers that did not, implement
the extension would not have been able to interoperate. This would this extension would not have been able to interoperate. This would
have been a significant limitation of such an extension. Link have been a significant limitation of such an extension. Link
metrics were therefore included as standard in OLSRv2. metrics were therefore included as standard in OLSRv2.
This document discusses the motivation and design rationale behind This document discusses the motivation and design rationale behind
how link metrics were included in OLSRv2. The principal issues how link metrics were included in OLSRv2. The principal issues
involved when including link metrics in OLSRv2 were: involved when including link metrics in OLSRv2 were:
o Assigning metrics to links involved considering separate metrics o Assigning metrics to links involved considering separate metrics
for the two directions of a link, with the receiving router for the two directions of a link, with the receiving router
determining the metric from transmitter to receiver. A metric determining the metric from transmitter to receiver. A metric
skipping to change at page 4, line 28 skipping to change at page 4, line 29
* A neighbor metric, the minimum of the link metrics between two * A neighbor metric, the minimum of the link metrics between two
OLSRv2 routers, in the indicated direction. OLSRv2 routers, in the indicated direction.
These metrics are necessarily the same when these routers each These metrics are necessarily the same when these routers each
have a single OLSRv2 interface, but may differ when either has have a single OLSRv2 interface, but may differ when either has
more. HELLO messages may include both link metrics and neighbor more. HELLO messages may include both link metrics and neighbor
metrics. TC messages include only neighbor metrics. metrics. TC messages include only neighbor metrics.
o Metrics as used in OLSRv2 are defined to be dimensionless and o Metrics as used in OLSRv2 are defined to be dimensionless and
additive. The assignment of metrics, including their relationship additive. The assignment of metrics, including their relationship
to real parameters such as data rate, loss rate and delay, is to real parameters such as data rate, loss rate and delay, and the
outside the scope of OLSRv2, which simply uses these metrics in a management of the choice of metric, is outside the scope of
consistent manner. However by use of a registry of metric types [OLSRv2], which simply uses these metrics in a consistent manner.
(employing extended types of a single address block TLV type), Within a single MANET, including all components of a temporarily
routers can be configured to use only a subset of the available fragmented MANET, a single choice of link metric is used. By use
metric types. of a registry of metric types (employing extended types of a
single Address Block TLV type), routers can be configured to use
only a subset of the available metric types.
o Node metrics were not included in OLSRv2. Node metrics can be o Node metrics were not included in OLSRv2. Node metrics can be
implemented by the addition of the corresponding value to all implemented by the addition of the corresponding value to all
incoming link metrics by the corresponding router. incoming link metrics by the corresponding router.
o The separation of the two functions performed by MPRs in OLSRv1, o The separation of the two functions performed by MultiPoint Relays
optimized flooding and reduced topology advertisement for routing, (MPRs) in OLSRv1, optimized flooding and reduced topology
into separate sets of MPRs in OLSRv2 [OLSRv2], denoted "flooding advertisement for routing, into separate sets of MPRs in OLSRv2
MPRs" and "routing MPRs". Flooding MPRs can be calculated as in [OLSRv2], denoted "flooding MPRs" and "routing MPRs". Flooding
[RFC3626], but the use of link metrics in OLSRv2 can improve the MPRs can be calculated as in [RFC3626], but the use of link
MPR selection. Routing MPRs need a metric-aware selection metrics in OLSRv2 can improve the MPR selection. Routing MPRs
algorithm. The selection of routing MPRs guarantees the use of need a metric-aware selection algorithm. The selection of routing
minimum distance routes using the chosen metric, while using only MPRs guarantees the use of minimum distance routes using the
symmetric 2-hop neighborhood information from HELLO messages and chosen metric, while using only symmetric 2-hop neighborhood
routing MPR selector information from TC messages. information from HELLO messages and routing MPR selector
information from TC messages.
o The protocol Information Bases defined in OLSRv2 include required o The protocol Information Bases defined in OLSRv2 include required
metric values. This has included additions to the protocol metric values. This has included additions to the protocol
Information Bases defined in NHDP [RFC6130] when used by OLSRv2. Information Bases defined in NHDP [RFC6130] when used by OLSRv2.
2. Terminology 2. Terminology
All terms introduced in [RFC5444], including "message" and "TLV", are All terms introduced in [RFC5444], including "message" and "TLV"
to be interpreted as described there. (type-length-value), are to be interpreted as described there.
All terms introduced in [RFC6130], including "MANET interface", All terms introduced in [RFC6130], including "MANET interface",
"HELLO message", "heard", "link", "symmetric link", "1-hop neighbor", "HELLO message", "heard", "link", "symmetric link", "1-hop neighbor",
"symmetric 1-hop neighbor", "2-hop neighbor", "symmetric 2-hop "symmetric 1-hop neighbor", "2-hop neighbor", "symmetric 2-hop
neighbor", and "symmetric 2-hop neighborhood", are to be interpreted neighbor", "symmetric 2-hop neighborhood", and the symbolic constants
as described there. SYMMETRIC and HEARD, are to be interpreted as described there.
All terms introduced in [OLSRv2], including "router", "OLSRv2 All terms introduced in [OLSRv2], including "router", "OLSRv2
interface", "willingness", "MultiPoint Relay (MPR)", "MPR selector", interface", "willingness", "MultiPoint Relay (MPR)", "MPR selector",
and "MPR flooding" are to be interpreted as described there. "MPR flooding" and the TLV type LINK_METRIC are to be interpreted as
described there.
3. Applicability 3. Applicability
The objective of this document is to retain the design considerations The objective of this document is to retain the design considerations
behind how link metrics were included in [OLSRv2]. This document behind how link metrics were included in [OLSRv2]. This document
does not prescribe any behavior, but explains some aspects of the does not prescribe any behavior, but explains some aspects of the
operation of OLSRv2. operation of OLSRv2.
4. Motivational Scenarios 4. Motivational Scenarios
skipping to change at page 7, line 46 skipping to change at page 8, line 46
A related case is that of a privileged relay. An example is an A related case is that of a privileged relay. An example is an
aerial router in an otherwise ground based network. The aerial aerial router in an otherwise ground based network. The aerial
router may have a link to many, or even all, other routers. That router may have a link to many, or even all, other routers. That
would lead to all routers attempting to send all their traffic (other would lead to all routers attempting to send all their traffic (other
than to symmetric 1-hop neighbors and some symmetric 2-hop neighbors) than to symmetric 1-hop neighbors and some symmetric 2-hop neighbors)
via the aerial router. It may however be important to reserve that via the aerial router. It may however be important to reserve that
capacity for cases where the aerial router is actually essential, capacity for cases where the aerial router is actually essential,
such as if the ground based portion of the network is not connected. such as if the ground based portion of the network is not connected.
Link metrics provide a possible solution to these scenarios. For
example, in Figure 1 the route A to Y to Z to B could be preferred to
A to X to B by making the metrics on the former path 1 and those on
the latter path 2. The aerial privileged relay could be used only
when necessary by giving its links maximal metric values, with much
smaller other metric values, or if the aerial link is to be preferred
to N ground links, giving the ground links metric values of 1, while
making the sum of the aerial node uplink and downlink metrics equal
to N.
Other cases may involve attempts to avoid areas of congestion, to Other cases may involve attempts to avoid areas of congestion, to
route around insecure routers (by preference, but prepared to use route around insecure routers (by preference, but prepared to use
them if there is no other alternative) and routers attempting to them if there is no other alternative) and routers attempting to
discourage their use as relays due to, for example, limited battery discourage their use as relays due to, for example, limited battery
power. OLSRv2 does have another mechanism to aid in this, a router's power. OLSRv2 does have another mechanism to aid in this, a router's
willingness to act as an MPR. However there are cases where that willingness to act as an MPR. However there are cases where that
cannot help, but where use of non-minimum hop routes could. cannot help, but where use of non-minimum hop routes could.
Similarly, note that OLSRv2's optional use of link quality (through Similarly, note that OLSRv2's optional use of link quality (through
its use of [RFC6130]) is not a solution to these problems. Use of its use of [RFC6130]) is not a solution to these problems. Use of
skipping to change at page 12, line 25 skipping to change at page 13, line 25
(incoming) case is used in OLSRv2 because, in general, receiving (incoming) case is used in OLSRv2 because, in general, receiving
routers have more information available to determine link metrics routers have more information available to determine link metrics
(for example received signal strength, interference levels, and error (for example received signal strength, interference levels, and error
control coding statistics). control coding statistics).
Note that, using directional metrics, if router A defines the metric Note that, using directional metrics, if router A defines the metric
of the link from router B to router A, then router B must use router of the link from router B to router A, then router B must use router
A's definition of that metric on that link in that direction. A's definition of that metric on that link in that direction.
(Router B could, if appropriate, use a bad mismatch between (Router B could, if appropriate, use a bad mismatch between
directional metrics as a reason to discontinue use of this link, directional metrics as a reason to discontinue use of this link,
using the link quality mechanism in [RFC6130].) using the link quality mechanism defined in [RFC6130]; note that this
is a distinct mechanism from the use of link metrics.)
5.4. Reporting Link and Neighbor Metrics 5.4. Reporting Link and Neighbor Metrics
Links, and hence link metrics, are reported in HELLO messages. A Links, and hence link metrics, are reported in HELLO messages. A
router must report incoming link metrics in its HELLO messages in router must report incoming link metrics in its HELLO messages in
order that these are each available at the other end of the link. order that these are each available at the other end of the link.
This means that, for a symmetric link, both ends of the link will This means that, for a symmetric link, both ends of the link will
know both of the incoming and outgoing link metrics. know both of the incoming and outgoing link metrics.
As well as advertising incoming link metrics, HELLO messages also As well as advertising incoming link metrics, HELLO messages also
skipping to change at page 14, line 5 skipping to change at page 15, line 7
responsible for defining and reporting incoming link metrics, it must responsible for defining and reporting incoming link metrics, it must
evaluate that metric, and attach that link metric to the appropriate evaluate that metric, and attach that link metric to the appropriate
address (which will have link status HEARD) in the next HELLO message address (which will have link status HEARD) in the next HELLO message
reporting that address on that OLSRv2 interface. There will, at this reporting that address on that OLSRv2 interface. There will, at this
time, be no outgoing link metric available to report, but a router time, be no outgoing link metric available to report, but a router
must be able to immediately decide on an incoming link metric once it must be able to immediately decide on an incoming link metric once it
has heard a 1-hop neighbor on an OLSRv2 interface for the first time. has heard a 1-hop neighbor on an OLSRv2 interface for the first time.
This is because, when receiving a HELLO message from this router, the This is because, when receiving a HELLO message from this router, the
1-hop neighbor seeing its own address listed with link status HEARD 1-hop neighbor seeing its own address listed with link status HEARD
will (unless link quality indicates otherwise) immediately consider will (unless the separate link quality mechanism indicates otherwise)
that link to be SYMMETRIC, advertise it with that link status in immediately consider that link to be SYMMETRIC, advertise it with
future HELLO messages, and use it (for MPR selection and data traffic that link status in future HELLO messages, and use it (for MPR
forwarding). selection and data traffic forwarding).
It may, depending on the physical nature of the link metric, be too It may, depending on the physical nature of the link metric, be too
early for an ideal decision as to that metric, however a choice must early for an ideal decision as to that metric, however a choice must
be made. The metric value may later be refined based on further be made. The metric value may later be refined based on further
observation of HELLO messages, other message transmissions between observation of HELLO messages, other message transmissions between
the routers, or other observations of the environment. It will the routers, or other observations of the environment. It will
probably be best to over-estimate the metric if initially uncertain probably be best to over-estimate the metric if initially uncertain
as to its value, to discourage, rather than over-encourage, its use. as to its value, to discourage, rather than over-encourage, its use.
If no information other than the receipt of the HELLO message is If no information other than the receipt of the HELLO message is
available, then a conservative maximum link metric value, denoted available, then a conservative maximum link metric value, denoted
MAXIMUM_METRIC in [OLSRv2], should be used. MAXIMUM_METRIC in [OLSRv2], should be used.
5.6. Link Metric Values 5.6. Link Metric Values
Link metric values are recorded in LINK_METRIC TLVs, defined in Link metric values are recorded in LINK_METRIC TLVs, defined in
[OLSRv2], using a compressed representation that occupies 12 bits. [OLSRv2], using a compressed (lossy) representation that occupies 12
The use of 12 bits is convenient because, when combined with 4 flag bits. The use of 12 bits is convenient because, when combined with 4
bits of additional information, described below, this results in a 2 flag bits of additional information, described below, this results in
octet value field. However the use of 12 bits was a consequence of a a 2 octet value field. However the use of 12 bits, and thus the
design to use a modified exponent/mantissa form with the following availability of 4 flag bits, was a consequence of a design to use a
characteristics: modified exponent/mantissa form with the following characteristics:
o The values represented are to be positive integers starting 1, 2, o The values represented are to be positive integers starting 1, 2,
... ...
o The maximum value represented should be close to, but less than o The maximum value represented should be close to, but less than
2^24 (^ denotes exponentiation in this section). This is so that 2^24 (^ denotes exponentiation in this section). This is so that
with a route limited to no more than 255 hops, the maximum route with a route limited to no more than 255 hops, the maximum route
metric is less than 2^32, i.e., can be stored in 32 bits. (The metric is less than 2^32, i.e., can be stored in 32 bits. (The
link metric value can be stored in 24 bits.) link metric value can be stored in 24 bits.)
A representation, modified from an exponent/mantissa form with e bits A representation, modified from an exponent/mantissa form with e bits
of exponent and m bits of mantissa, and which has the first of these of exponent and m bits of mantissa, and which has the first of these
properties is one that starts at 1, then is incremented by 1 up to properties is one that starts at 1, then is incremented by 1 up to
2^m, then has a further 2^m increments by 2, then a further 2^m 2^m, then has a further 2^m increments by 2, then a further 2^m
increments by 4, and so on for 2^e sets of increments. increments by 4, and so on for 2^e sets of increments. This means
that the represented value is never in error by more than a half (if
rounding) or one (if truncating) part in 2^m, usually less.
The position in the increment sequence, from 0 to 2^m-1, is The position in the increment sequence, from 0 to 2^m-1, is
considered as a form of mantissa, and denoted a. The increment considered as a form of mantissa, and denoted a. The increment
sequence number, from 0 to 2^e-1, is considered as a form of sequence number, from 0 to 2^e-1, is considered as a form of
exponent, and denoted b. exponent, and denoted b.
The value represented by (a,b) can then be shown to be equal to (2^m+ The value represented by (b,a) can then be shown to be equal to (2^m+
a+1)2^b-2^m. To verify this, note that: a+1)2^b-2^m. To verify this, note that:
o With fixed b, the difference between two values with consecutive o With fixed b, the difference between two values with consecutive
values of a is 2^b, as expected. values of a is 2^b, as expected.
o The value represented by (b,2^m-1) is (2^m+2^m)2^b-2^m. The value o The value represented by (b,2^m-1) is (2^m+2^m)2^b-2^m. The value
represented by (b+1,0) is (2^m+1)(2^(b+1))-2^m. The difference represented by (b+1,0) is (2^m+1)(2^(b+1))-2^m. The difference
between these two values is 2^(b+1), as expected. between these two values is 2^(b+1), as expected.
The maximum represented value has b = 2^e-1 and a = 2^m-1, and is The maximum represented value has b = 2^e-1 and a = 2^m-1, and is
(2^m+2^m)(2^(2^e-1))-2^m = 2^(2^e+m)-2^m. This is slightly less than (2^m+2^m)(2^(2^e-1))-2^m = 2^(2^e+m)-2^m. This is slightly less than
2^(2^e+m). The required 24 bit limit can be achieved if 2^e+m = 24. 2^(2^e+m). The required 24 bit limit can be achieved if 2^e+m = 24.
An appropriate pair of values to achieve this is e = 4, m = 8. Of the possible (e,m) pairs that satisfy this equation, the pair e =
4, m = 8 was selected as most appropriate, and is that used by
OLSRv2. It uses the previously indicated e+m = 12 bits. An
algorithm for converting from a 24 bit value v to a 12 bit pair (b,a)
is given in Section 6.2 of [OLSRv2].
As noted above, the 12 bit representation shares two octets with 4 As noted above, the 12 bit representation then shares two octets with
flag bits. Putting the flag bits first, it is then natural to put 4 flag bits. Putting the flag bits first, it is then natural to put
the exponent bits in the last four bits of the first octet, and to the exponent bits in the last four bits of the first octet, and to
put the mantissa bits in the second octet. The 12 consecutive bits, put the mantissa bits in the second octet. The 12 consecutive bits,
using network byte order (most significant octet first), then using network byte order (most significant octet first), then
represent 256b+a. Note that the ordering of these 12 bit represent 256b+a. Note that the ordering of these 12 bit
representation values is the same as the ordering of the 24 bit representation values is the same as the ordering of the 24 bit
metric values. In other words, two 12 bit metrics fields can be metric values. In other words, two 12 bit metrics fields can be
compared for equality/ordering as if they were unsigned integers. compared for equality/ordering as if they were unsigned integers.
The four flag bits each represent one kind of metric, defined by its The four flag bits each represent one kind of metric, defined by its
direction (incoming or outgoing) and whether the metric is a link direction (incoming or outgoing) and whether the metric is a link
skipping to change at page 16, line 40 skipping to change at page 17, line 40
using metrics. The relationship between these two sets of MPRs is using metrics. The relationship between these two sets of MPRs is
considered in Section 6.3. considered in Section 6.3.
6.1. Flooding MPRs 6.1. Flooding MPRs
The essential detail of the "flooding MPR" selection specification is The essential detail of the "flooding MPR" selection specification is
that a router must select a set of MPRs such that a message that a router must select a set of MPRs such that a message
transmitted by a router, and re-transmitted by all its flooding MPRs, transmitted by a router, and re-transmitted by all its flooding MPRs,
will reach all of the selecting router's symmetric 2-hop neighbors. will reach all of the selecting router's symmetric 2-hop neighbors.
Flooding MPR selection can ignore metrics and produce produce a Flooding MPR selection can ignore metrics and produce a solution that
solution that meets the required specification. However, that does meets the required specification. However, that does not mean that
not mean that metrics cannot be usefully considered in selecting metrics cannot be usefully considered in selecting flooding MPRs.
flooding MPRs. Consider the network in Figure 2, where numbers are Consider the network in Figure 2, where numbers are metrics of links
metrics of links in the direction away from router A, towards router in the direction away from router A, towards router D.
D.
3 3
A ----- B A ----- B
| | | |
1 | | 1 1 | | 1
| | | |
C ----- D C ----- D
4 4
Figure 2 Figure 2
skipping to change at page 24, line 7 skipping to change at page 25, line 7
Figure 10 Figure 10
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
This section may be removed by the RFC Editor. This section may be removed by the RFC Editor.
8. Security Considerations 8. Security Considerations
No new security issues arose from the inclusion of metrics in OLSRv2, An attacker can have an adverse impact on an OLSRv2 network by
and hence the subject did not receive any additional discussion. The creating apparently valid messages that contain incorrect link
security considerations in [OLSRv2] cover the complete protocol, and metrics. This could take the form of influencing the choice of
thus there is nothing further to say in this document. routes, or in some cases producing routing loops. This is a more
subtle, and likely to be less effective, attack, than other forms of
invalid message injection. These can add and remove other and more
basic forms of network information, such as the existence of some
routers and links.
As such, no significantly new security issues arose from the
inclusion of metrics in OLSRv2. Defenses to the injection of invalid
link metrics are the same as to other forms of invalid message
injection, as discussed in the security considerations section of
[OLSRv2].
There are possible uses for link metrics in the creation of security
countermeasures, to prefer the use of links that have better security
properties, including better availability, to those with poorer
security properties. This however is beyond the scope of both this
document and [OLSRv2].
9. Acknowledgements 9. Acknowledgements
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
documents and its components (listed alphabetically): Brian Adamson documents and its components (listed alphabetically): Brian Adamson
(NRL), Alan Cullen (BAE Systems), Justin Dean (NRL), Ulrich Herberg (NRL), Alan Cullen (BAE Systems), Justin Dean (NRL), Ulrich Herberg
(Fujitsu), Stan Ratliff (Cisco), Charles Perkins (Huawei), and (Fujitsu), Stan Ratliff (Cisco), Charles Perkins (Huawei), and
Henning Rogge (FGAN). Henning Rogge (FGAN).
Finally, the authors would like to express their gratitude to Adrian Finally, the authors would like to express their gratitude to (listed
Farrel, for his review and comments on the later versions of this alphabetically) Benoit Claise, Adrian Farrel, Stephen Farrell and
document. Suresh Krishnan for their reviews and comments on the later versions
of this document.
10. Informative References 10. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and (MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999. Evaluation Considerations", RFC 2501, January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
 End of changes. 23 change blocks. 
80 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/