< draft-lavenu-lln-loadng-interoperability-report-03.txt		draft-lavenu-lln-loadng-interoperability-report-04.txt >
	Network Working Group T. Clausen		Network Working Group T. Clausen
	Internet-Draft A. Camacho		Internet-Draft A. Camacho
	Intended status: Informational J. Yi		Intended status: Informational J. Yi
	Expires: April 25, 2013 A. Colin de Verdiere		Expires: June 14, 2013 A. Colin de Verdiere
	LIX, Ecole Polytechnique		LIX, Ecole Polytechnique
	Y. Igarashi		Y. Igarashi
	H. Satoh		H. Satoh
	Y. Morii		Y. Morii
	Hitachi, Ltd., Yokohama Research		Hitachi, Ltd., Yokohama Research
	Laboratory		Laboratory
	U. Herberg		U. Herberg
	Fujitsu Laboratories of America		Fujitsu Laboratories of America
	C. Lavenu		C. Lavenu
	EDF R&D		EDF R&D
	October 22, 2012		December 11, 2012
	Interoperability Report of the Lightweight On-demand Ad hoc Distance-		Interoperability Report for the Lightweight On-demand Ad hoc Distance-
	vector Routing Protocol - Next Generation (LOADng)		vector Routing Protocol - Next Generation (LOADng)
	draft-lavenu-lln-loadng-interoperability-report-03		draft-lavenu-lln-loadng-interoperability-report-04
	Abstract		Abstract
	This document reports experience with the LOADng routing protocol, as		This document reports experience with the LOADng routing protocol, as
	obtained by way of a number of interoperability tests during the		obtained by way of a number of interoperability tests during the
	protocol development.		protocol development.
	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
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 25, 2013.		This Internet-Draft will expire on June 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 31 ¶		skipping to change at page 2, line 31 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Interoperability Scenarios . . . . . . . . . . . . . . . . . . 6		3. Interoperability Scenarios . . . . . . . . . . . . . . . . . . 5
	3.1. Scenario 01: 1-hop Bidirectional Route Establishment -		3.1. Scenario 01: 1-hop Bidirectional Route Establishment -
	Forward Route and Reverse Route initial installation . . . 6		Forward Route and Reverse Route initial installation . . . 5
	3.1.1. Scenario Topology . . . . . . . . . . . . . . . . . . 6		3.1.1. Scenario Topology . . . . . . . . . . . . . . . . . . 5
	3.1.2. Expected Message Sequencing . . . . . . . . . . . . . 6		3.1.2. Expected Message Sequencing . . . . . . . . . . . . . 6
	3.2. Scenario 02: 1-hop Bidirectional Route Establishment		3.2. Scenario 02: 1-hop Bidirectional Route Establishment
	-Forward Route and Reverse Route updating . . . . . . . . 7		-Forward Route and Reverse Route updating . . . . . . . . 6
	3.2.1. Scenario Topology . . . . . . . . . . . . . . . . . . 7		3.2.1. Scenario Topology . . . . . . . . . . . . . . . . . . 6
	3.2.2. Expected Message Sequencing . . . . . . . . . . . . . 7		3.2.2. Expected Message Sequencing . . . . . . . . . . . . . 7
	3.3. Scenario 03: 2-hop bidirectional route establishment -		3.3. Scenario 03: 2-hop bidirectional route establishment -
	Forward Route and Reverse Route initial installation . . . 8		Forward Route and Reverse Route initial installation . . . 7
	3.3.1. Scenario Topology . . . . . . . . . . . . . . . . . . 8		3.3.1. Scenario Topology . . . . . . . . . . . . . . . . . . 8
	3.3.2. Expected Message Sequencing . . . . . . . . . . . . . 9		3.3.2. Expected Message Sequencing . . . . . . . . . . . . . 8
	3.4. Scenario 04: 2-hop bidirectional route establishment -		3.4. Scenario 04: 2-hop bidirectional route establishment -
	Forward Route and Reverse Route updating . . . . . . . . . 10		Forward Route and Reverse Route updating . . . . . . . . . 9
	3.4.1. Scenario Topology . . . . . . . . . . . . . . . . . . 10		3.4.1. Scenario Topology . . . . . . . . . . . . . . . . . . 9
	3.4.2. Expected Message Sequencing . . . . . . . . . . . . . 10		3.4.2. Expected Message Sequencing . . . . . . . . . . . . . 9
	3.5. Scenario 05: 2-hop bidirectional route establishment -		3.5. Scenario 05: 2-hop bidirectional route establishment -
	Link breakage handling . . . . . . . . . . . . . . . . . . 11		Link breakage handling . . . . . . . . . . . . . . . . . . 10
	3.5.1. Scenario Topology . . . . . . . . . . . . . . . . . . 11		3.5.1. Scenario Topology . . . . . . . . . . . . . . . . . . 10
	3.5.2. Expected Message Sequencing . . . . . . . . . . . . . 11		3.5.2. Expected Message Sequencing . . . . . . . . . . . . . 11
	3.6. Scenario 06: 3-hop bidirectional route establishment -		3.6. Scenario 06: 3-hop bidirectional route establishment -
	Forward Route and Reverse Route initial installation . . . 12		Forward Route and Reverse Route initial installation . . . 11
	3.6.1. Scenario Topology . . . . . . . . . . . . . . . . . . 12		3.6.1. Scenario Topology . . . . . . . . . . . . . . . . . . 12
	3.6.2. Expected Message Sequencing . . . . . . . . . . . . . 13		3.6.2. Expected Message Sequencing . . . . . . . . . . . . . 12
	3.7. Scenario 07: 3-hop bidirectional route establishment -		3.7. Scenario 07: 3-hop bidirectional route establishment -
	Forward Route and Reverse Route updating . . . . . . . . . 14		Forward Route and Reverse Route updating . . . . . . . . . 13
	3.7.1. Scenario Topology . . . . . . . . . . . . . . . . . . 14		3.7.1. Scenario Topology . . . . . . . . . . . . . . . . . . 14
	3.7.2. Expected Message Sequencing . . . . . . . . . . . . . 15		3.7.2. Expected Message Sequencing . . . . . . . . . . . . . 14
	3.8. Scenario 08: 3-hop bidirectional route establishment -		3.8. Scenario 08: 3-hop bidirectional route establishment -
	Link breakage handling . . . . . . . . . . . . . . . . . . 16		Link breakage handling . . . . . . . . . . . . . . . . . . 15
	3.8.1. Scenario Topology . . . . . . . . . . . . . . . . . . 16		3.8.1. Scenario Topology . . . . . . . . . . . . . . . . . . 15
	3.8.2. Expected Message Sequencing . . . . . . . . . . . . . 16		3.8.2. Expected Message Sequencing . . . . . . . . . . . . . 16
	3.9. Scenario 09: 4-hop bidirectional route establishment -		3.9. Scenario 09: 4-hop bidirectional route establishment -
	Forward Route and Reverse Route initial installation . . . 17		Forward Route and Reverse Route initial installation . . . 16
	3.9.1. Scenario Topology . . . . . . . . . . . . . . . . . . 18		3.9.1. Scenario Topology . . . . . . . . . . . . . . . . . . 17
	3.9.2. Expected Message Sequencing . . . . . . . . . . . . . 18		3.9.2. Expected Message Sequencing . . . . . . . . . . . . . 17
	3.10. Scenario 10: 4-hop bidirectional route establishment -		3.10. Scenario 10: 4-hop bidirectional route establishment -
	Link breakage handling . . . . . . . . . . . . . . . . . . 20		Link breakage handling . . . . . . . . . . . . . . . . . . 19
	3.10.1. Scenario Topology . . . . . . . . . . . . . . . . . . 20		3.10.1. Scenario Topology . . . . . . . . . . . . . . . . . . 19
	3.10.2. Expected Message Sequencing . . . . . . . . . . . . . 21		3.10.2. Expected Message Sequencing . . . . . . . . . . . . . 20
	3.11. Scenario 11: Establishment of the best bidirectional		3.11. Scenario 11: Establishment of the best bidirectional
	route . . . . . . . . . . . . . . . . . . . . . . . . . . 22		route . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	3.11.1. Scenario Topology . . . . . . . . . . . . . . . . . . 22		3.11.1. Scenario Topology . . . . . . . . . . . . . . . . . . 21
	3.11.2. Expected Message Sequencing . . . . . . . . . . . . . 22		3.11.2. Expected Message Sequencing . . . . . . . . . . . . . 21
	3.12. Scenario 12: Blacklisting . . . . . . . . . . . . . . . . 23		3.12. Scenario 12: Blacklisting . . . . . . . . . . . . . . . . 22
	3.12.1. Scenario Topology . . . . . . . . . . . . . . . . . . 24		3.12.1. Scenario Topology . . . . . . . . . . . . . . . . . . 23
	3.12.2. Expected Message Sequencing . . . . . . . . . . . . . 24		3.12.2. Expected Message Sequencing . . . . . . . . . . . . . 23
	4. Interop 01: Yokohama, Japan, October 2011 . . . . . . . . . . 27		4. Interop 01: Yokohama, Japan, October 2011 . . . . . . . . . . 26
	4.1. Version of LOADng Specification Tested . . . . . . . . . . 27		4.1. Version of LOADng Specification Tested . . . . . . . . . . 26
	4.2. Place and Date of Interoperability Test . . . . . . . . . 28		4.2. Place and Date of Interoperability Test . . . . . . . . . 27
	4.3. Participating Implementations . . . . . . . . . . . . . . 28		4.3. Participating Implementations . . . . . . . . . . . . . . 27
	4.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 28		4.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 27
	4.5. Additional Interoperability Test Considerations . . . . . 28		4.5. Additional Interoperability Test Considerations . . . . . 27
	4.6. Results For Scenario 01 . . . . . . . . . . . . . . . . . 29		4.6. Results For Scenario 01 . . . . . . . . . . . . . . . . . 28
	4.7. Results For Scenario 02 . . . . . . . . . . . . . . . . . 29		4.7. Results For Scenario 02 . . . . . . . . . . . . . . . . . 28
	4.8. Results For Scenario 03 . . . . . . . . . . . . . . . . . 29		4.8. Results For Scenario 03 . . . . . . . . . . . . . . . . . 28
	4.9. Results For Scenario 04 . . . . . . . . . . . . . . . . . 30		4.9. Results For Scenario 04 . . . . . . . . . . . . . . . . . 29
	4.10. Results For Scenario 05 . . . . . . . . . . . . . . . . . 30		4.10. Results For Scenario 05 . . . . . . . . . . . . . . . . . 29
	4.11. Results For Scenario 06 . . . . . . . . . . . . . . . . . 31		4.11. Results For Scenario 06 . . . . . . . . . . . . . . . . . 30
	4.12. Results For Scenario 07 . . . . . . . . . . . . . . . . . 31		4.12. Results For Scenario 07 . . . . . . . . . . . . . . . . . 30
	4.13. Results For Scenario 08 . . . . . . . . . . . . . . . . . 31		4.13. Results For Scenario 08 . . . . . . . . . . . . . . . . . 30
	4.14. Results For Scenario 09 . . . . . . . . . . . . . . . . . 32		4.14. Results For Scenario 09 . . . . . . . . . . . . . . . . . 31
	4.15. Results For Scenario 10 . . . . . . . . . . . . . . . . . 32		4.15. Results For Scenario 10 . . . . . . . . . . . . . . . . . 31
	4.16. Results For Scenario 11 . . . . . . . . . . . . . . . . . 32		4.16. Results For Scenario 11 . . . . . . . . . . . . . . . . . 31
	4.17. Results For Scenario 12 . . . . . . . . . . . . . . . . . 33		4.17. Results For Scenario 12 . . . . . . . . . . . . . . . . . 32
	4.18. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 33		4.18. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 32
	5. Interop 02: San Jose, USA March 2012 . . . . . . . . . . . . . 35		5. Interop 02: San Jose, USA March 2012 . . . . . . . . . . . . . 34
	5.1. LOADng version tested . . . . . . . . . . . . . . . . . . 35		5.1. LOADng version tested . . . . . . . . . . . . . . . . . . 34
	5.2. Place and Date of Interoperability Test . . . . . . . . . 35		5.2. Place and Date of Interoperability Test . . . . . . . . . 34
	5.3. Participating Implementations . . . . . . . . . . . . . . 35		5.3. Participating Implementations . . . . . . . . . . . . . . 34
	5.4. Interoperability Test Considerations . . . . . . . . . . . 36		5.4. Interoperability Test Considerations . . . . . . . . . . . 35
	5.5. Results For Scenario 01 . . . . . . . . . . . . . . . . . 36		5.5. Results For Scenario 01 . . . . . . . . . . . . . . . . . 35
	5.6. Results For Scenrio 03 . . . . . . . . . . . . . . . . . . 36		5.6. Results For Scenrio 03 . . . . . . . . . . . . . . . . . . 35
	5.7. Results For Scenario 05 . . . . . . . . . . . . . . . . . 36		5.7. Results For Scenario 05 . . . . . . . . . . . . . . . . . 35
	6. Interop 03: Los Angeles, USA, June 2012 . . . . . . . . . . . 37		6. Interop 03: Los Angeles, USA, June 2012 . . . . . . . . . . . 36
	6.1. Version of LOADng Specification Tested . . . . . . . . . . 37		6.1. Version of LOADng Specification Tested . . . . . . . . . . 36
	6.2. Place and Date of Interoperability Test . . . . . . . . . 37		6.2. Place and Date of Interoperability Test . . . . . . . . . 36
	6.3. Participating Implementations . . . . . . . . . . . . . . 37		6.3. Participating Implementations . . . . . . . . . . . . . . 36
	6.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 37		6.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 36
	6.5. Additional Interoperability Test Considerations . . . . . 37		6.5. Additional Interoperability Test Considerations . . . . . 36
	6.6. Results For Scenario 01-02 . . . . . . . . . . . . . . . . 38		6.6. Results For Scenario 01-02 . . . . . . . . . . . . . . . . 37
	6.7. Results For Scenario 03-04-05 . . . . . . . . . . . . . . 38		6.7. Results For Scenario 03-04-05 . . . . . . . . . . . . . . 37
	6.8. Results For Scenario 06-07-08 . . . . . . . . . . . . . . 39		6.8. Results For Scenario 06-07-08 . . . . . . . . . . . . . . 38
	6.9. Results For Scenario 09-10 . . . . . . . . . . . . . . . . 40		6.9. Results For Scenario 09-10 . . . . . . . . . . . . . . . . 39
	6.10. Results For Scenario 11 . . . . . . . . . . . . . . . . . 40		6.10. Results For Scenario 11 . . . . . . . . . . . . . . . . . 39
	6.11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 40		6.11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 39
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 41		7. Interop 04: Vancouver, Canada, August, 2011 . . . . . . . . . 39
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		7.1. Version of LOADng Specifiation Tested . . . . . . . . . . 39
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41		7.2. Place and Date of Interoperability Test . . . . . . . . . 40
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41		7.3. Participating Implementations . . . . . . . . . . . . . . 40
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41		7.4. Scenarios Tested . . . . . . . . . . . . . . . . . . . . . 40
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 41		7.5. Additional Interoperability Test Considerations . . . . . 40
	11.2. Informative References . . . . . . . . . . . . . . . . . . 42		7.6. Results for Scenario 01-02 . . . . . . . . . . . . . . . . 40
			7.7. Results for Scenario 03-04-05 . . . . . . . . . . . . . . 41
			7.8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 43
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
			10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
			11. Informative References . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	This document reports experience with the LOADng [LOADng] routing		This document reports experience with the LOADng [LOADng] routing
	protocol, as obtained by way of a number of interoperability tests		protocol, as obtained by way of a number of interoperability tests
	during the protocol development.		during the protocol development.
	Interoperability tests between LOADng Routers implemented on the		Interoperability tests between LOADng Routers implemented on the
	basis of the different versions of the protocol have been undertaken		basis of the different versions of the protocol have been undertaken
	mainly to:		mainly to:
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	o Clarify and improve the overall quality of the LOADng		o Clarify and improve the overall quality of the LOADng
	specification.		specification.
	o Demonstrate that the final LOADng internet draft can be considered		o Demonstrate that the final LOADng internet draft can be considered
	as a standalone specification allowing the development of		as a standalone specification allowing the development of
	interoperable implementations of LOADng.		interoperable implementations of LOADng.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document uses the terminology of [LOADng].
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].
	Additionally, this document uses the following terminology:
	LOADng Router - A router which implements this routing protocol.
	Destination - The address of a router or host, to which a route is
	sought discovered and maintained.
	Originator - The address of a router, which seeks to discover and
	maintain a route to a Destination.
	Forward Route - A route set up so as to send data packets from the
	Originator to the Destination. The Forward Route is set up when a
	LOADng Router forwards Route Reply (RREP) messages.
	Reverse Route - A route set up so as to send data packets from the
	Destination to the Originator. The Reverse Route is set up when a
	LOADng Router forwards Route Request (RREQ) messages. It is used
	for forwarding RREP messages, as well as for forwarding data
	packets.
	Route Cost - The sum of the Link Costs for the links that a RREQ or
	RREP has crossed.
	Weak Link - A link which is marginally usable, i.e., MAY be used if
	no other links are available, but SHOULD be avoided if at all
	possible - even if it entails an ultimately longer path. As an
	example, a Weak Link might be defined as a link with a significant
	loss-rate.
	3. Interoperability Scenarios		3. Interoperability Scenarios
	This section describes the various tests and scenarios carried out		This section describes the various tests and scenarios carried out
	between the implementations involved in the various interoperability		between the implementations involved in the various interoperability
	tests.		tests.
	The testbed required is composed of up to five LOADng Routers,		The testbed required is composed of up to five LOADng Routers,
	connected according to the specific topology described for each test		connected according to the specific topology described for each test
	scenario below. The LOADng routing protocol was run over UDP and		scenario below. The LOADng routing protocol was run over UDP and
	skipping to change at page 39, line 10 ¶		skipping to change at page 37, line 50 ¶
	The following table is summarizing the results obtained for the		The following table is summarizing the results obtained for the
	different combinations for which these test 1 (Forward Route and		different combinations for which these test 1 (Forward Route and
	Reverse Route initial installation) and test 2 (Forward Route and		Reverse Route initial installation) and test 2 (Forward Route and
	Reverse Route updating) were performed:		Reverse Route updating) were performed:
	+-----+-----+-----+--------+--------+		+-----+-----+-----+--------+--------+
	| A | B | C | Test 1 | Test 2 |		| A | B | C | Test 1 | Test 2 |
	+-----+-----+-----+--------+--------+		+-----+-----+-----+--------+--------+
	| LIX | FLA | LIX | Pass | Pass |		| LIX | FLA | LIX | Pass | Pass |
	| LIX | LIX | FLA | Pass | Pass |		| LIX | LIX | FLA | Pass | Pass |
	| FLA | LIX | LIX | Pass | Pass |
	+-----+-----+-----+--------+--------+		+-----+-----+-----+--------+--------+
	Table 18		Table 18
	The following table is summarizing the results obtained for the		The following table is summarizing the results obtained for the
	different combinations for which these test 3 (Link breakage		different combinations for which these test 3 (Link breakage
	handling) was performed:		handling) was performed:
	+-----+-----+-----+--------+		+-----+-----+-----+--------+
	| A | B | C | Test 3 |		| A | B | C | Test 3 |
	+-----+-----+-----+--------+		+-----+-----+-----+--------+
	| FLA | LIX | LIX | Pass |		| FLA | LIX | LIX | Pass |
	skipping to change at page 40, line 47 ¶		skipping to change at page 39, line 38 ¶
	+-----+-----+-----+--------+		+-----+-----+-----+--------+
	| LIX | FLA | LIX | Pass |		| LIX | FLA | LIX | Pass |
	| LIX | LIX | FLA | Pass |		| LIX | LIX | FLA | Pass |
	| FLA | LIX | LIX | Pass |		| FLA | LIX | LIX | Pass |
	+-----+-----+-----+--------+		+-----+-----+-----+--------+
	Table 23		Table 23
	6.11. Conclusions		6.11. Conclusions
	The different test scenarios carried that were carried out for		The different test scenarios that were carried out for different
	different interoperable and independent implementations allowed to		interoperable and independent implementations allowed to cover all
	cover all major features of the LOADng specification by checking each		major features of the LOADng specification by checking each technical
	technical feature one by one. In addition, the completion of this		feature one by one. In addition, the completion of this process
	process permitted the improvement of the overall quality and accuracy		permitted the improvement of the overall quality and accuracy of the
	of the [LOADng] specification.		[LOADng] specification.
	7. Security Considerations		7. Interop 04: Vancouver, Canada, August, 2011
			7.1. Version of LOADng Specifiation Tested
			The interoperability tests were conducted according to the
			specification in [LOADng-05].
			7.2. Place and Date of Interoperability Test
			This section reports experience with the LOADng routing protocol,
			resulting from interoperability testing performed at Hyatt Hotel,
			Vancouver, August 2nd, 2012.
			7.3. Participating Implementations
			The following implementations were used to perform the
			interoperability tests this section, listed alphabetically:
			Ecole Polytechnique: "LIX" - This implementation was jointly
			developed by Axel Colin de Verdiere, Jiazi Yi, Ulrich Herberg and
			Thomas Clausen of Ecole Ploytechnique's networking team. It
			consists of approximately 6000 lines of JAVA code running in a Mac
			OS environment. It supports RREQ, RREP, RREP-ACK and RERR
			generation, processing, forwarding and transmission.
			Fujitsu Laboratories of America: "FLA" - This implementation was
			developed by Ulrich Herberg from Fujitsu Laboratories of America.
			It is a Java implementation, supporting all LOADng features (RREQ,
			RREP, RREP-ACK generation, processing, forwarding and
			transmission).
			7.4. Scenarios Tested
			This interoperability test includes scenarios 01-05 (inclusive).
			7.5. Additional Interoperability Test Considerations
			For each test, the initiation of the communication resulting in the
			generation of the first LOADng control traffic message is always
			triggered manually. In addition, RREP-ACK LOADng control messages
			were systematically expected from each LOADng Router upon reception
			of an RREP LOADng control message in order to allow the detection of
			unidirectional links.
			In this interop event, the use of different metrics types in the
			protocol were specifically considered.
			7.6. Results for Scenario 01-02
			The following table summarizes the results obtained for the different
			combinations for which test 1 (Forward Route and Reverse Route
			initial installation) was performed:
			+-----+------+------+
			| | LIX | FLA |
			+-----+------+------+
			| LIX | N/R | Pass |
			| FLA | Pass | N/R |
			+-----+------+------+
			Table 24
			The following table summarizes the results obtained for the different
			combinations for which test 2 (Forward Route and Reverse Route
			updating) was performed:
			+-----+------+------+
			| | LIX | FLA |
			+-----+------+------+
			| LIX | N/R | Pass |
			| FLA | Pass | N/R |
			+-----+------+------+
			Table 25
			7.7. Results for Scenario 03-04-05
			The following table summarizes the results obtained for the different
			combinations for which these test 1 (Forward Route and Reverse Route
			initial installation) and test 2 (Forward Route and Reverse Route
			updating) were performed:
			+-----+-----+-----+--------+--------+
			| A | B | C | Test 1 | Test 2 |
			+-----+-----+-----+--------+--------+
			| LIX | FLA | LIX | Pass | Pass |
			| LIX | LIX | FLA | Pass | Pass |
			+-----+-----+-----+--------+--------+
			Table 26
			The following table is summarizing the results obtained for the
			different combinations for which these test 3 (Link breakage
			handling) was performed:
			+-----+-----+-----+--------+
			| A | B | C | Test 3 |
			+-----+-----+-----+--------+
			| FLA | LIX | LIX | Pass |
			| LIX | FLA | LIX | Pass |
			+-----+-----+-----+--------+
			Table 27
			In addition to conventional scenarios as described in Scenario 03 and
			Scenario 04 with the same metric type (HOP_COUNT, type 0), different
			metric types are tested in the same network. In the test, the
			originator of the RREQ initiates a route discovery using a metric
			type that the intermediate router does not understand (type 1).
			The following table summarizes the results obtained for the different
			combinations for which these test 1 (Forward Route and Reverse Route
			initial installation) and test 2 (Forward Route and Reverse Route
			updating), with different metric types:
			+-----+-----+-----+--------+--------+
			| A | B | C | Test 1 | Test 2 |
			+-----+-----+-----+--------+--------+
			| LIX | FLA | LIX | Pass | Pass |
			| LIX | LIX | FLA | Pass | Fail |
			+-----+-----+-----+--------+--------+
			Table 28
			One of the tests failed because handling unknown metric types was not
			defined properly in [LOADng-05] (but corrected in [LOADng-06], as a
			direct result of this interop test). Some changes from [LOADng-05]
			to [LOADng-06] that were proposed (and integrated in [LOADng-06]):
			1. In section 13.1 ("RREP Generation"):
			o RREP.metric-type set to the same value as the RREQ.metric-type
			in the corresponding RREQ;
			is changed to
			o RREP.metric-type set to the same value as the RREQ.metric-type
			in the corresponding RREQ if the metric type is known to the
			router. Otherwise, RREP.metric-type is set to HOP_COUNT.
			Rationale: If a router that generates an RREP for an incoming
			RREQ does not know the metric from the RREQ, it will use the
			HOP_COUNT metric as fall-back. Per definition, all routers
			running LOADng support the HOP_COUNT metric.
			2. In section 12.3 ("RREQ forwarding"):
			3. RREQ.route-metric := received-route-metric + link-metric
			is changed to
			3. If used-metric-type is not HOP_COUNT, then RREQ.route-metric
			:= route-metric + link-metric
			Rationale: When the HOP_COUNT metric is used, the metric TLV
			value should remain unchanged, and instead the hop count from the
			message header is used to calculate the distance.
			7.8. Conclusions
			As an intermediate test, and because of the limited time, only a
			subset of the scenarios (01, 02, 03, 04, 05) have been tested. In
			the performed tests, in addition to the conventional behaviors
			(regular message exchanges), different metric types, especially
			unknown metric types have been used in the network.
			The results show that for scenarios with only one metric type, the
			two implementations are able to interoperate with each other.
			However, when different metrics exist in the same network, the test
			failed in some scenarios. The problems are identified, and
			corresponding resolutions are proposed. The updates have been
			integrated in [LOADng-06].
			8. Security Considerations
	This document does currently not specify any security considerations.		This document does currently not specify any security considerations.
	8. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	9. Contributors		10. Contributors
	This specification is the result of the joint efforts of the		This specification is the result of the joint efforts of the
	following contributors -- listed alphabetically.		following contributors -- listed alphabetically.
	o Alberto Camacho, LIX, France, <alberto@albertocamacho.com>		o Alberto Camacho, LIX, France, <alberto@albertocamacho.com>
	o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>		o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
	o Axel Colin de Verdiere, LIX, France, <axel@axelcdv.com>		o Axel Colin de Verdiere, LIX, France, <axel@axelcdv.com>
	o Ulrich Herberg, Fujitsu Laboratories of America, USA,		o Ulrich Herberg, Fujitsu Laboratories of America, USA,
	<ulrich.herberg@us.fujitsu.com>		<ulrich.herberg@us.fujitsu.com>
	o Yuichi Igarashi, HITACHI YRL, Japan,		o Yuichi Igarashi, HITACHI YRL, Japan,
	<yuichi.igarashi.hb@hitachi.com>		<yuichi.igarashi.hb@hitachi.com>
	o Nobukatsu Inomata, HITACHI ULSI Systems, Japan,		o Nobukatsu Inomata, HITACHI ULSI Systems, Japan,
	<nobukatsu.inomata.rf@hitachi.com>		<nobukatsu.inomata.rf@hitachi.com>
	o Yoko Morii, HITACHI YRL, Japan, <yoko.morii.cs@hitachi.com>		o Yoko Morii, HITACHI YRL, Japan, <yoko.morii.cs@hitachi.com>
	o Hiroki Satoh, HITACHI YRL, Japan, <hiroki.satoh.yj@hitachi.com>		o Hiroki Satoh, HITACHI YRL, Japan, <hiroki.satoh.yj@hitachi.com>
	o Jiazi Yi, LIX, France, <jiazi@jiaziyi.com>		o Jiazi Yi, LIX, France, <jiazi@jiaziyi.com>
	10. Acknowledgments		11. Informative References
	TBD
	11. References
	11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.
	11.2. Informative References
	[LOADng] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,		[LOADng] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,
	Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys,		Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys,
	T., and C. Perkins, "The LLN On-demand Ad hoc Distance-		T., Perkins, C., and J. Dean, "The Lightweight On-demand
	vector Routing Protocol - Next Generation (LOADng)",		Ad hoc Distance-vector Routing Protocol - Next
	draft-clausen-lln-loadng (work in progress), July 2012.		Generation (LOADng)", draft-clausen-lln-loadng (work in
			progress), October 2012.
	[LOADng-00] Clausen, T., Colin de Verdiere, A., Yi, J., Lavenu, C.,		[LOADng-00] Clausen, T., Colin de Verdiere, A., Yi, J., Lavenu, C.,
	Lys, T., Niktash, A., Igarashi, Y., and H. Satoh, "The		Lys, T., Niktash, A., Igarashi, Y., and H. Satoh, "The
	LLN On-demand Ad hoc Distance-vector Routing Protocol -		LLN On-demand Ad hoc Distance-vector Routing Protocol -
	Next Generation (LOADng)", draft-clausen-lln-loadng-00		Next Generation (LOADng)", draft-clausen-lln-loadng-00
	(work in progress), October 2011.		(work in progress), October 2011.
	[LOADng-03] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,		[LOADng-03] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,
	Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., and T.		Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., and T.
	Lys, "The LLN On-demand Ad hoc Distance-vector Routing		Lys, "The LLN On-demand Ad hoc Distance-vector Routing
	skipping to change at page 42, line 40 ¶		skipping to change at page 45, line 9 ¶
	draft-clausen-lln-loadng-04 (work in progress),		draft-clausen-lln-loadng-04 (work in progress),
	April 2012.		April 2012.
	[LOADng-05] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,		[LOADng-05] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,
	Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys,		Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys,
	T., and C. Perkins, "The LLN On-demand Ad hoc Distance-		T., and C. Perkins, "The LLN On-demand Ad hoc Distance-
	vector Routing Protocol - Next Generation (LOADng)",		vector Routing Protocol - Next Generation (LOADng)",
	draft-clausen-lln-loadng-05 (work in progress),		draft-clausen-lln-loadng-05 (work in progress),
	July 2012.		July 2012.
			[LOADng-06] Clausen, T., Colin de Verdiere, A., Yi, J., Niktash, A.,
			Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys,
			T., Perkins, C., and J. Dean, "The Lightweight On-demand
			Ad hoc Distance-vector Routing Protocol - Next
			Generation (LOADng)", draft-clausen-lln-loadng-06 (work
			in progress), October 2012.
	Authors' Addresses		Authors' Addresses
	Thomas Heide Clausen		Thomas Heide Clausen
	LIX, Ecole Polytechnique		LIX, Ecole Polytechnique
	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/
	Alberto Camacho		Alberto Camacho
	LIX, Ecole Polytechnique		LIX, Ecole Polytechnique
	Phone: +34 636 309 835		Phone: +34 636 309 835
	EMail: alberto@albertocamacho.com		EMail: alberto@albertocamacho.com
	URI: http://www.albertocamacho.com/		URI: http://www.albertocamacho.com/
	Jiazi Yi		Jiazi Yi
	LIX, Ecole Polytechnique		LIX, Ecole Polytechnique
End of changes. 32 change blocks.
	141 lines changed or deleted		283 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/