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/