draft-ietf-manet-olsrv2-metrics-rationale-01.txt   draft-ietf-manet-olsrv2-metrics-rationale-02.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: April 12, 2013 LIX, Ecole Polytechnique, France Expires: August 26, 2013 LIX, Ecole Polytechnique, France
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
October 9, 2012 February 22, 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-01 draft-ietf-manet-olsrv2-metrics-rationale-02
Abstract Abstract
This document describes the rationale for and design considerations OLSRv2 includes the ability to assign metrics to links and to use
behind how link metrics are included in OLSRv2, in order to allow those metrics to allow routing by other than minimum hop count
routing by other than minimum hop count routes. routes. This document provides a historic record of the rationale
for, and design considerations behind, how link metrics were included
in OLSRv2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 12, 2013. This Internet-Draft will expire on August 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
(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
the distinguishing features of the Optimized Link State Routing the distinguishing features of the Optimized Link State Routing
Protocol version 2 (OLSRv2) [OLSRv2] is the introduction of the Protocol version 2 (OLSRv2) [OLSRv2] is the introduction of the
ability to select routes using link metrics other than the number of ability to select routes using link metrics other than the number of
hops. hops.
During the development of OLSRv2 the working group and authors
repeatedly discussed how and why some choices were made in the
protocol specification, particularly at the metric integration level.
Some of the issues may be non-intuitive and this document is
presented as a record of the considerations and decisions to provide
informational discussion about motivation and historic design
choices. This document is intended to be useful as a reference if
those questions arise again.
OLSRv2 essentially first determines local link metrics from 1-hop OLSRv2 essentially first determines local link metrics from 1-hop
neighbors, these being defined by a process outside OLSRv2, then neighbors, these being defined by a process outside OLSRv2, then
distributes required link metric values in HELLO messages and TC distributes required link metric values in HELLO messages and TC
messages, and then finally forms routes with minimum total link messages, and then finally forms routes with minimum total link
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)
skipping to change at page 4, line 17 skipping to change at page 4, line 26
the receiving router. the receiving router.
* 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 were 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, is
outside the scope of OLSRv2, which simply uses these metrics in a outside the scope of OLSRv2, which simply uses these metrics in a
consistent manner. However by use of a registry of metric types consistent manner. However by use of a registry of metric types
(employing extended types of a single address block TLV type), (employing extended types of a single address block TLV type),
routers can use only metrics of the physical type that they are routers can be configured to use only a subset of the available
configured to use. metric types.
o The separation of the two functions performed by MPRs in OLSRv1, o The separation of the two functions performed by MPRs in OLSRv1,
optimized flooding and reduced topology advertisement for routing, optimized flooding and reduced topology advertisement for routing,
into separate sets of MPRs in OLSRv2 [OLSRv2], denoted "flooding into separate sets of MPRs in OLSRv2 [OLSRv2], denoted "flooding
MPRs" and "routing MPRs". Flooding MPRs can be calculated as in MPRs" and "routing MPRs". Flooding MPRs can be calculated as in
[RFC3626], but the use of link metrics in OLSRv2 can improve the [RFC3626], but the use of link metrics in OLSRv2 can improve the
MPR selection. Routing MPRs need a metric-aware selection MPR selection. Routing MPRs need a metric-aware selection
algorithm. The selection of routing MPRs guarantees the use of algorithm. The selection of routing MPRs guarantees the use of
minimum distance routes using the chosen metric, while using only minimum distance routes using the chosen metric, while using only
symmetric 2-hop neighborhood information from HELLO messages and symmetric 2-hop neighborhood information from HELLO messages and
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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", are
to be interpreted as described there. 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", and "symmetric 2-hop neighborhood", are to be interpreted
as described there. 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. and "MPR flooding" are to be interpreted as described there.
3. Applicability 3. Applicability
skipping to change at page 18, line 5 skipping to change at page 18, line 5
However, this is a particularly simple example. Usually it is not a However, this is a particularly simple example. Usually it is not a
simple choice between two routers as a flooding MPR, each only adding simple choice between two routers as a flooding MPR, each only adding
one router coverage. A more general process, when considering which one router coverage. A more general process, when considering which
router to next add as a flooding MPR, should incorporate the metric router to next add as a flooding MPR, should incorporate the metric
to that router, and the metric from that router to each symmetric to that router, and the metric from that router to each symmetric
2-hop neighbor, as well as the number of newly covered symmetric 2-hop neighbor, as well as the number of newly covered symmetric
2-hop neighbors, and may include other factors. 2-hop neighbors, and may include other factors.
The required specification for flooding MPR selection is in Section The required specification for flooding MPR selection is in Section
18.4 (also using Section 18.3) of [OLSRv2]. which may use the example 18.4 (also using Section 18.3) of [OLSRv2]. which may use the example
MPR selection algorithm in Appendix A of [OLSRv2]. However, note MPR selection algorithm in Appendix B of [OLSRv2]. However, note
that (as in [RFC3626]) each router can make its own independent that (as in [RFC3626]) each router can make its own independent
choice of flooding MPRs, and flooding MPR selection algorithm, and choice of flooding MPRs, and flooding MPR selection algorithm, and
still interoperate. still interoperate.
Also note that the references above to the direction of the metrics Also note that the references above to the direction of the metrics
is correct: for flooding, directional metrics outward from a router is correct: for flooding, directional metrics outward from a router
are appropriate, i.e., metrics in the direction of the flooding. are appropriate, i.e., metrics in the direction of the flooding.
This is an additional reason for including outward metrics in HELLO This is an additional reason for including outward metrics in HELLO
messages, as otherwise a metric-aware MPR selection for flooding is messages, as otherwise a metric-aware MPR selection for flooding is
not possible. The second hop metrics are outgoing neighbor metrics not possible. The second hop metrics are outgoing neighbor metrics
skipping to change at page 21, line 27 skipping to change at page 21, line 27
metric between two routers (on different OLSRv2 interfaces), then, metric between two routers (on different OLSRv2 interfaces), then,
considering symmetric links only (as only these are used for routing) considering symmetric links only (as only these are used for routing)
the smallest link metric, i.e., the neighbor metric, is used. There the smallest link metric, i.e., the neighbor metric, is used. There
is no need to calculate routing MPRs per OLSRv2 interface. That is no need to calculate routing MPRs per OLSRv2 interface. That
requirement results from the consideration of flooding and the need requirement results from the consideration of flooding and the need
to avoid certain "race" conditions, which are not relevant to to avoid certain "race" conditions, which are not relevant to
routing, only to flooding. routing, only to flooding.
The required specification for routing MPR selection is in Section The required specification for routing MPR selection is in Section
18.5 (also using Section 18.3) of [OLSRv2]. which may use the example 18.5 (also using Section 18.3) of [OLSRv2]. which may use the example
MPR selection algorithm in Appendix A of [OLSRv2]. However, note MPR selection algorithm in Appendix B of [OLSRv2]. However, note
that (as in [RFC3626]) each router can make its own independent that (as in [RFC3626]) each router can make its own independent
choice of routing MPRs, and routing MPR selection algorithm, and choice of routing MPRs, and routing MPR selection algorithm, and
still interoperate. still interoperate.
6.3. Relationship Between MPR Sets 6.3. Relationship Between MPR Sets
It would be convenient if the two sets of flooding and routing MPRs It would be convenient if the two sets of flooding and routing MPRs
were the same. This can be the case if all metrics are equal, but in were the same. This can be the case if all metrics are equal, but in
general, for "good" sets of MPRs they are not. (A reasonable general, for "good" sets of MPRs they are not. (A reasonable
definition of this is that there is no common minimal set of MPRs.) definition of this is that there is no common minimal set of MPRs.)
skipping to change at page 25, line 9 skipping to change at page 25, line 9
8. Security Considerations 8. Security Considerations
This document does not specify any security considerations. This document does not specify any security considerations.
This section may be removed by the RFC Editor. This section may be removed by the RFC Editor.
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
specification and its components (listed alphabetically): Brian documents and its components (listed alphabetically): Brian Adamson
Adamson (NRL), Alan Cullen (BAE Systems), Justin Dean (NRL), Stan (NRL), Alan Cullen (BAE Systems), Justin Dean (NRL), Ulrich Herberg
Ratliff (Cisco), Charles Perkins (Huawei), Henning Rogge (FGAN), and (Fujitsu), Stan Ratliff (Cisco), Charles Perkins (Huawei), and
Ulrich Herberg (Fujitsu). Henning Rogge (FGAN).
Finally, the authors would like to express their gratitude to Adrian
Farrel, for his review 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.
[RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, [RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
draft-ietf-manet-olsrv2-16.txt (work in progress), draft-ietf-manet-olsrv2-17.txt (work in progress),
October 2012. October 2012.
Appendix A. MPR Routing Property Appendix A. MPR Routing Property
In order that routers can find and use shortest routes in a network In order that routers can find and use shortest routes in a network
while using the minimum reduced topology supported by OLSRv2 (that a while using the minimum reduced topology supported by OLSRv2 (that a
router only advertises its MPR selectors in TC messages), routing MPR router only advertises its MPR selectors in TC messages), routing MPR
selection must result in the property that there are shortest routes selection must result in the property that there are shortest routes
with all intermediate routers being routing MPRs. with all intermediate routers being routing MPRs.
skipping to change at page 29, line 25 skipping to change at page 29, line 25
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Philippe Jacquet Philippe Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Phone: +33 6 7337 1880 Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.fr EMail: philippe.jacquet@alcatel-lucent.com
 End of changes. 15 change blocks. 
21 lines changed or deleted 36 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/