draft-ietf-manet-olsrv2-metrics-rationale-02.txt   draft-ietf-manet-olsrv2-metrics-rationale-03.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: August 26, 2013 LIX, Ecole Polytechnique, France Expires: October 11, 2013 LIX, Ecole Polytechnique
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
February 22, 2013 April 9, 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-02 draft-ietf-manet-olsrv2-metrics-rationale-03
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 August 26, 2013. This Internet-Draft will expire on October 11, 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 4, line 35 skipping to change at page 4, line 35
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, 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 be configured to use only a subset of the available routers can be configured to use only a subset of the available
metric types. metric types.
o Node metrics were not included in OLSRv2. Node metrics can be
implemented by the addition of the corresponding value to all
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 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
routing MPR selector information from TC messages. routing MPR selector information from TC messages.
skipping to change at page 24, line 7 skipping to change at page 24, 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
This document does not specify any security considerations. No new security issues arose from the inclusion of metrics in OLSRv2,
and hence the subject did not receive any additional discussion. The
This section may be removed by the RFC Editor. security considerations in [OLSRv2] cover the complete protocol, and
thus there is nothing further to say in this document.
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).
skipping to change at page 26, line 24 skipping to change at page 26, line 24
[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., Jacquet, P., and U. Herberg, [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
draft-ietf-manet-olsrv2-17.txt (work in progress), draft-ietf-manet-olsrv2-19.txt (work in progress),
October 2012. March 2013.
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.
This appendix uses the following terminology and assumptions: This appendix uses the following terminology and assumptions:
skipping to change at page 29, line 8 skipping to change at page 29, line 8
routable path, and demonstrates the n-arc routable path property for routable path, and demonstrates the n-arc routable path property for
n = k+1. n = k+1.
This thus shows that for any distinct nodes X and Z, there is a This thus shows that for any distinct nodes X and Z, there is a
routable path using the MPR-reduced topology from X to Z, i.e., that routable path using the MPR-reduced topology from X to Z, i.e., that
OLSRv2 finds minimum length paths (minimum total metric routes). OLSRv2 finds minimum length paths (minimum total metric routes).
Authors' Addresses Authors' Addresses
Christopher Dearlove Christopher Dearlove
BAE Systems ATC BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique
91128 Palaiseau Cedex
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.com EMail: philippe.jacquet@alcatel-lucent.com
 End of changes. 10 change blocks. 
12 lines changed or deleted 22 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/