draft-ietf-roll-p2p-rpl-11.txt		draft-ietf-roll-p2p-rpl-12.txt
	Internet Engineering Task Force M. Goyal, Ed.		Internet Engineering Task Force M. Goyal, Ed.
	Internet-Draft University of Wisconsin		Internet-Draft University of Wisconsin
	Intended status: Experimental Milwaukee		Intended status: Experimental Milwaukee
	Expires: November 7, 2012 E. Baccelli		Expires: November 9, 2012 E. Baccelli
	M. Philipp		M. Philipp
	INRIA		INRIA
	A. Brandt		A. Brandt
	Sigma Designs		Sigma Designs
	J. Martocci		J. Martocci
	Johnson Controls		Johnson Controls
	May 6, 2012		May 8, 2012
	Reactive Discovery of Point-to-Point Routes in Low Power and Lossy		Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
	Networks		Networks
	draft-ietf-roll-p2p-rpl-11		draft-ietf-roll-p2p-rpl-12
	Abstract		Abstract
	This document specifies a point-to-point route discovery mechanism,		This document specifies a point-to-point route discovery mechanism,
	complementary to the RPL core functionality. This mechanism allows		complementary to the RPL core functionality. This mechanism allows
	an IPv6 router to discover "on demand" routes to one or more IPv6		an IPv6 router to discover "on demand" routes to one or more IPv6
	routers in the LLN such that the discovered routes meet specified		routers in the LLN such that the discovered routes meet specified
	metrics constraints.		metrics constraints.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 November 7, 2012.		This Internet-Draft will expire on November 9, 2012.
	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 34		skipping to change at page 2, line 34
	7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15		7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15
	8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15		8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15
	8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17		8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18		8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18
	9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18		9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18
	9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18		9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18
	9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19		9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19
	9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21		9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21
	9.4. Additional Processing of a P2P Mode DIO At An		9.4. Additional Processing of a P2P Mode DIO At An
	Intermediate Router . . . . . . . . . . . . . . . . . . . 22		Intermediate Router . . . . . . . . . . . . . . . . . . . 22
	9.5. Additional Processing of a P2P Mode DIO At The Target . . 22		9.5. Additional Processing of a P2P Mode DIO At The Target . . 23
	9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24		9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24
	9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25		9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25
	10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27		10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27
	11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27		11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27
	12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28		12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 29		13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29		14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 29
	14.2. Additions to RPL Control Message Options . . . . . . . . . 30		14.2. Additions to RPL Control Message Options . . . . . . . . . 30
	14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30		14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30
	14.4. New Registry for Upper Layer Headers inside Data Option . 30		14.4. New Registry for Upper Layer Headers inside Data Option . 31
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	16.1. Normative References . . . . . . . . . . . . . . . . . . . 31		16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	16.2. Informative References . . . . . . . . . . . . . . . . . . 31		16.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	Targeting Low power and Lossy Networks (LLNs), the RPL routing		Targeting Low power and Lossy Networks (LLNs), the RPL routing
	protocol [RFC6550] provides paths along a Directed Acyclic Graph		protocol [RFC6550] provides paths along a Directed Acyclic Graph
	(DAG) rooted at a single router in the network. Establishment and		(DAG) rooted at a single router in the network. Establishment and
	maintenance of a DAG is performed by routers in the LLN using DODAG		maintenance of a DAG is performed by routers in the LLN using DODAG
	Information Object (DIO) messages. When two arbitrary routers		Information Object (DIO) messages. When two arbitrary routers
	(neither of which is the DAG's root) need to communicate, the data		(neither of which is the DAG's root) need to communicate, the data
	packets are restricted to travel only along the links in the DAG.		packets are restricted to travel only along the links in the DAG.
	skipping to change at page 9, line 8		skipping to change at page 9, line 8
	flag in the DRO message to let the nodes in the LLN know about the		flag in the DRO message to let the nodes in the LLN know about the
	completion of the route discovery process. The routers receiving		completion of the route discovery process. The routers receiving
	such a DRO should not generate any more DIOs for this temporary DAG.		such a DRO should not generate any more DIOs for this temporary DAG.
	Neither should they process any received DIOs for this temporary DAG		Neither should they process any received DIOs for this temporary DAG
	in future. However, such routers must still process the DROs		in future. However, such routers must still process the DROs
	received for this temporary DAG.		received for this temporary DAG.
	6. P2P Route Discovery Mode Of Operation		6. P2P Route Discovery Mode Of Operation
	This section specifies a new RPL Mode of Operation (MOP), P2P Route		This section specifies a new RPL Mode of Operation (MOP), P2P Route
	Discovery mode (or P2P mode, for short), with value 4 (to be		Discovery Mode (or P2P mode, for short), with value 4 (to be
	confirmed by IANA). A DIO message, listing P2P mode as the MOP, is		confirmed by IANA). A DIO message, listing P2P mode as the MOP, is
	identified as performing a P2P-RPL route discovery by creating a		identified as performing a P2P-RPL route discovery by creating a
	temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route		temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route
	Discovery Option (specified in Section 7.1).		Discovery Option (specified in Section 7.1).
	6.1. Setting a P2P Mode DIO		6.1. Setting a P2P Mode DIO
	The Base Object in a P2P mode DIO message MUST be set in the		The Base Object in a P2P mode DIO message MUST be set in the
	following manner:		following manner:
	skipping to change at page 15, line 30		skipping to change at page 15, line 30
	o Option Length: An 8-bit unsigned integer, representing the length		o Option Length: An 8-bit unsigned integer, representing the length
	in octets of the option, not including the Option Type and Option		in octets of the option, not including the Option Type and Option
	Length fields.		Length fields.
	o SeqNo: A 4-bit field representing the sequence number of the data		o SeqNo: A 4-bit field representing the sequence number of the data
	carried by the Data Option.		carried by the Data Option.
	o Upper: A 4-bit field that identifies the upper layer protocol		o Upper: A 4-bit field that identifies the upper layer protocol
	header with which the information in the Data field starts. A		header with which the information in the Data field starts. A
	value 0x00 in this field identifies UDP as the upper layer		value 0x0 in this field identifies UDP as the upper layer protocol
	protocol. The other values are reserved at present.		while the value 0xF is reserved for Private Use as defined in
			[RFC5226]. The other values are Unassigned [RFC5226] at present.
	o Data: If the Data Option is contained in a DIO, this field		o Data: If the Data Option is contained in a DIO, this field
	contains application data to be delivered to the Target(s). If		contains application data to be delivered to the Target(s). If
	the Data Option is contained in a DRO, this field contains		the Data Option is contained in a DRO, this field contains
	application data to be delivered to the Origin.		application data to be delivered to the Origin.
	8. The Discovery Reply Object (DRO)		8. The Discovery Reply Object (DRO)
	This section defines two new RPL Control Message types, the Discovery		This section defines two new RPL Control Message types, the Discovery
	Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the		Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the
	skipping to change at page 21, line 8		skipping to change at page 21, line 8
	deployments where specific destinations are reachable only through		deployments where specific destinations are reachable only through
	specific intermediate routers (and hence these intermediate		specific intermediate routers (and hence these intermediate
	routers should not suppress their DIOs). A particular deployment		routers should not suppress their DIOs). A particular deployment
	should take in account typical loss rates, the topological		should take in account typical loss rates, the topological
	characteristics of the LLN (the average/typical connectivity of		characteristics of the LLN (the average/typical connectivity of
	the nodes and the variance in connectivity: whether some		the nodes and the variance in connectivity: whether some
	destinations have only a small set of neighbors) and the need to		destinations have only a small set of neighbors) and the need to
	contain the message overhead of the route discovery when deciding		contain the message overhead of the route discovery when deciding
	the value of the redundancy constant.		the value of the redundancy constant.
			Applicability Statements that specify the use of P2P-RPL MUST provide
			guidance for setting Trickle parameters, particularly Imin and the
			redundancy constant.
	9.3. Processing a P2P Mode DIO		9.3. Processing a P2P Mode DIO
	The rules for DIO processing and transmission, described in Section 8		The rules for DIO processing and transmission, described in Section 8
	of RPL [RFC6550], apply to P2P mode DIOs as well except as modified		of RPL [RFC6550], apply to P2P mode DIOs as well except as modified
	in this document.		in this document.
	The following rules for processing a received P2P mode DIO apply to		The following rules for processing a received P2P mode DIO apply to
	both Intermediate Routers and the Target.		both Intermediate Routers and the Target.
	A router SHOULD discard a received P2P mode DIO with no further		A router SHOULD discard a received P2P mode DIO with no further
	skipping to change at page 29, line 45		skipping to change at page 29, line 45
	of a DRO message traveling in a routing loop, this document requires		of a DRO message traveling in a routing loop, this document requires
	each Intermediate Router to confirm that the Source Route listed		each Intermediate Router to confirm that the Source Route listed
	inside the message does not contain any routing loop involving itself		inside the message does not contain any routing loop involving itself
	before the router could forward the message further. As specified in		before the router could forward the message further. As specified in
	Section 9.6, this check involves the router making sure that its IPv6		Section 9.6, this check involves the router making sure that its IPv6
	addresses do not appear multiple times inside the Source Route with		addresses do not appear multiple times inside the Source Route with
	one or more other IPv6 addresses in between.		one or more other IPv6 addresses in between.
	14. IANA Considerations		14. IANA Considerations
	14.1. Additions to DIO Mode of Operation		14.1. Additions to Mode of Operation
	IANA is requested to allocate a new value in the "DIO Mode of		This document defines a new Mode of Operation, entitled "P2P Route
	Operation" registry for the "P2P Route Discovery Mode" described in		Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode
	this document.		of Operation" space [to be removed upon publication:
	+----------+-----------------------------------------+--------------+		http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550].
	| MOP | Description | Reference |
	| Value | | |
	+----------+-----------------------------------------+--------------+
	| 4 | Reactive P2P route discovery mode of | This |
	| | operation | document |
	+----------+-----------------------------------------+--------------+
	DIO Mode of Operation		+-------+---------------------------------------+---------------+
			| Value | Description | Reference |
			+-------+---------------------------------------+---------------+
			| 4 | P2P Route Discovery Mode of Operation | This document |
			+-------+---------------------------------------+---------------+
			Mode of Operation
	14.2. Additions to RPL Control Message Options		14.2. Additions to RPL Control Message Options
	IANA is requested to allocate new values in the "RPL Control Message		This document defines two new RPL options:
	Options" registry for the "P2P Route Discovery Option" and the "Data
	Option" described in this document.		o "P2P Route Discovery Option" (see Section 7.1), assigned a value
			of 0x0A from the "RPL Control Message Options" space [to be
			removed upon publication: http://www.iana.org/assignments/rpl/
			rpl.xml#control-message-options] [RFC6550].
			o "Data Option" (see Section 7.2), assigned a value of 0x0B from the
			"RPL Control Message Options" space [to be removed upon
			publication: http://www.iana.org/assignments/rpl/
			rpl.xml#control-message-options] [RFC6550].
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| Value | Meaning | Reference |		| Value | Meaning | Reference |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	| 10 | P2P Route Discovery | This document |		| 0x0A | P2P Route Discovery | This document |
	| 11 | Data | This document |		| 0x0B | Data | This document |
	+-------+---------------------+---------------+		+-------+---------------------+---------------+
	RPL Control Message Options		RPL Control Message Options
	14.3. Additions to RPL Control Codes		14.3. Additions to RPL Control Codes
	IANA is requested to allocate new code points in the "RPL Control		This document defines the following new RPL messages:
	Codes" registry for the "Discovery Reply Object" and "Discovery Reply
	Object Acknowledgement" (and their secure versions) described in this		o "Discovery Reply Object" (see Section 8), assigned a value of 0x04
	document.		from the "RPL Control Codes" space [to be removed upon
			publication:
			http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
			[RFC6550].
			o "Discovery Reply Object Acknowledgement" (see Section 10),
			assigned a value of 0x05 from the "RPL Control Codes" space [to be
			removed upon publication:
			http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
			[RFC6550].
			o "Secure Discovery Reply Object" (see Section 8.1), assigned a
			value of 0x84 from the "RPL Control Codes" space [to be removed
			upon publication:
			http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
			[RFC6550].
			o "Secure Discovery Reply Object Acknowledgement" (see Section 10),
			assigned a value of 0x85 from the "RPL Control Codes" space [to be
			removed upon publication:
			http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
			[RFC6550].
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| Code | Description | Reference |		| Code | Description | Reference |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	| 0x04 | Discovery Reply Object | This document |		| 0x04 | Discovery Reply Object | This document |
	| 0x05 | Discovery Reply Object Acknowledgement | This document |		| 0x05 | Discovery Reply Object Acknowledgement | This document |
	| 0x84 | Secure Discovery Reply Object | This document |		| 0x84 | Secure Discovery Reply Object | This document |
	| 0x85 | Secure Discovery Reply Object | This document |		| 0x85 | Secure Discovery Reply Object | This document |
	| | Acknowledgement | |		| | Acknowledgement | |
	+------+--------------------------------------------+---------------+		+------+--------------------------------------------+---------------+
	RPL Control Codes		RPL Control Codes
	14.4. New Registry for Upper Layer Headers inside Data Option		14.4. New Registry for Upper Layer Headers inside Data Option
	This document creates a new IANA registry for the Upper Layer Header		The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for
	type inside the RPL Data Option, with the following initial content:		which IANA is requested to create and maintain a new registry titled
			"Upper Layer Header Type Inside RPL Data Option". New codes may be
			allocated in this registry only by an IETF Review [RFC5226]. Each
			code is tracked with the following characteristics:
	+-------+-------------+---------------+		o Value
	| Value | Description | Reference |
	+-------+-------------+---------------+
	| 0x00 | UDP Header | This document |
	+-------+-------------+---------------+
	Upper Layer Header Types inside RPL Data Option		o Description
			o Reference
			The following codes are currently defined:
			+---------+-------------+---------------+
			| Value | Description | Reference |
			+---------+-------------+---------------+
			| 0x0 | UDP Header | This document |
			| 0x1-0xE | Unassigned | |
			| 0xF | Private Use | This document |
			+---------+-------------+---------------+
			Upper Layer Header Types Inside RPL Data Option
	15. Acknowledgements		15. Acknowledgements
	Authors gratefully acknowledge the contributions of the following		Authors gratefully acknowledge the contributions of the following
	individuals (in alphabetical order) in the development of this		individuals (in alphabetical order) in the development of this
	document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard		document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard
	Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP		Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP
	Vasseur.		Vasseur.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,		[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
	"The Trickle Algorithm", RFC 6206, March 2011.		"The Trickle Algorithm", RFC 6206, March 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
	[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.		[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
	Barthel, "Routing Metrics Used for Path Calculation in		Barthel, "Routing Metrics Used for Path Calculation in
End of changes. 21 change blocks.
	44 lines changed or deleted		95 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/