draft-ietf-roll-rpl-18.txt		draft-ietf-roll-rpl-18-jari.txt
	skipping to change at page 8, line 26		skipping to change at page 8, line 26
	offer unique challenges to a routing solution: the IETF ROLL Working		offer unique challenges to a routing solution: the IETF ROLL Working
	Group has defined application-specific routing requirements for a Low		Group has defined application-specific routing requirements for a Low
	power and Lossy Network (LLN) routing protocol, specified in		power and Lossy Network (LLN) routing protocol, specified in
	[RFC5867], [RFC5826], [RFC5673], and [RFC5548].		[RFC5867], [RFC5826], [RFC5673], and [RFC5548].
	This document specifies the IPv6 Routing Protocol for Low power and		This document specifies the IPv6 Routing Protocol for Low power and
	lossy networks (RPL). Note that although RPL was specified according		lossy networks (RPL). Note that although RPL was specified according
	to the requirements set forth in the aforementioned requirement		to the requirements set forth in the aforementioned requirement
	documents, its use is in no way limited to these applications.		documents, its use is in no way limited to these applications.
	1.1. Design Principles		1.1. Design Principles and Assumptions
	RPL was designed with the objective to meet the requirements spelled		RPL was designed with the objective to meet the requirements spelled
	out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].		out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].
	A network may run multiple instances of RPL concurrently. Each such		A network may run multiple instances of RPL concurrently. Each such
	instance may serve different and potentially antagonistic constraints		instance may serve different and potentially antagonistic constraints
	or performance criteria. This document defines how a single instance		or performance criteria. This document defines how a single instance
	operates.		operates.
	In order to be useful in a wide range of LLN application domains, RPL		In order to be useful in a wide range of LLN application domains,
	separates packet processing and forwarding from the routing		RPL separates packet processing and forwarding from the routing
	optimization objective. Examples of such objectives include		optimization objective. Examples of such objectives include
	minimizing energy, minimizing latency, or satisfying constraints.		minimizing energy, minimizing latency, or satisfying constraints.
	This document describes the mode of operation of RPL. Other		This document describes the mode of operation of RPL. Other
	companion documents specify routing objective functions. A RPL		companion documents specify routing objective functions and
	implementation, in support of a particular LLN application, will		possibly associated metrics. A particular application may require
	include the necessary objective function(s) as required by the		specific objective function(s), but the as a baseline only the
	application.		default objective function is required (see Section 3.2.1).
			RPL routes are optimized for traffic to or from one or more roots
			that act as sinks for the topology.
			This specification has two major modes. Implementations are
			expected to support either no downward routes, non-storing mode
			only, or storing mode only (see Section 3.3).
	RPL operations require bidirectional links. It is required that the		RPL operations require bidirectional links. It is required that the
	reachability of a router is verified before the router can be used as		reachability of a router is verified before the router can be used as
	a parent. RPL expects an external mechanism to be triggered during		a parent. RPL expects an external mechanism to be triggered during
	the parent selection phase in order to verify link properties and		the parent selection phase in order to verify link properties and
	neighbor reachability. Neighbor Unreachability Detection (NUD) is		neighbor reachability. Neighbor Unreachability Detection (NUD) is
	such a mechanism, but alternates are possible, including		such a mechanism, but alternates are possible, including
	Bidirectional Forwarding Detection [RFC5881] and hints from lower		Bidirectional Forwarding Detection [RFC5881] and hints from lower
	layers via L2 triggers like [RFC5184]. In a general fashion, a		layers via L2 triggers like [RFC5184]. In a general fashion, a
	detection mechanism that is reactive to traffic is favored in order		detection mechanism that is reactive to traffic is favored in order
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option		the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option
	[I-D.ietf-6man-rpl-option] is an example of such mechanism. The		[I-D.ietf-6man-rpl-option] is an example of such mechanism. The
	mechanism is required for all packets except when strict source		mechanism is required for all packets except when strict source
	routing is used (that is for packets going downward in non-storing		routing is used (that is for packets going downward in non-storing
	mode as detailed further in Section 9), which by nature prevents		mode as detailed further in Section 9), which by nature prevents
	endless loops and alleviates the need for the RPL Packet Information.		endless loops and alleviates the need for the RPL Packet Information.
	Future companion specifications may propose alternate ways to carry		Future companion specifications may propose alternate ways to carry
	the RPL Packet Information in the IPv6 packets and may extend the RPL		the RPL Packet Information in the IPv6 packets and may extend the RPL
	Packet Information to support additional features.		Packet Information to support additional features.
			***Question about the above. Is the strick source routing mode
			applicable to both up and downward traffic? If only the the latter,
			then 6man-rpl-option is still mandatory for all implementations, to
			support the other direction. I'm assuming this is the case, please
			fix the above text and Section 1.3 if this is not the case.
			***Besides, this document says in Section 5 that all packets have
			an RPL instance, so it would seem that -option is always needed.
			***Finally, why isn't -rpl-routing-header mentioned here? This is
			needed... (But its unclear to me if its needed in *all* modes.
			Please add something about this here, and modify Section 1.3
			accordingly.)
	RPL provides a mechanism to disseminate information over the		RPL provides a mechanism to disseminate information over the
	dynamically-formed network topology. The dissemination enables		dynamically-formed network topology. The dissemination enables
	minimal configuration in the nodes, allowing nodes to operate mostly		minimal configuration in the nodes, allowing nodes to operate mostly
	autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to		autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to
	optimize the dissemination as described in Section 8.3.		optimize the dissemination as described in Section 8.3. An
			implementation of trickle is a mandatory part of RPL. However,
			some advanced aspects of RPL, such as the use of non-default
			objective function, security, and multiple simultaneous instances
			may require configuration. Configuration mechanisms for parameters
			necessary to control these advanced features are a subject for
			future specifications.
	In some applications, RPL assembles topologies of routers that own		In some applications, RPL assembles topologies of routers that own
	independent prefixes. Those prefixes may or may not be aggregatable		independent prefixes. Those prefixes may or may not be aggregatable
	depending on the origin of the routers. A prefix that is owned by a		depending on the origin of the routers. A prefix that is owned by a
	router is advertised as on-link.		router is advertised as on-link.
	RPL also introduces the capability to bind a subnet together with a		RPL also introduces the capability to bind a subnet together with a
	common prefix and to route within that subnet. A source can inject		common prefix and to route within that subnet. A source can inject
	information about the subnet to be disseminated by RPL, and that		information about the subnet to be disseminated by RPL, and that
	source is authoritative for that subnet. Because many LLN links have		source is authoritative for that subnet. Because many LLN links have
	non-transitive properties, a common prefix that RPL disseminates over		non-transitive properties, a common prefix that RPL disseminates over
	the subnet must not be advertised as on-link.		the subnet must not be advertised as on-link.
	RPL may in particular disseminate IPv6 Neighbor Discovery (ND)		RPL may in particular disseminate IPv6 Neighbor Discovery (ND)
	information such as the [RFC4861] Prefix Information Option (PIO) and		information such as the [RFC4861] Prefix Information Option (PIO)
	the [RFC4191] Route Information Option (RIO). ND information that is		and the [RFC4191] Route Information Option (RIO). Without such
	disseminated by RPL conserves all its original semantics for router		distribution, the automatic configuration capabilities for RPL
	to host, with limited extensions for router to router, though it is		routers would be of limited value. An RPL implementation is
	not to be confused with routing advertisements and it is never to be		required to support distribution of ND information to non-RPL
	directly redistributed in another routing protocol. A RPL node often		nodes, but the exact specification for this is subject to future
	combines host and router behaviors. As a host, it will process the		specifications.
	options as specified in [RFC4191], [RFC4861], [RFC4862] and
	[RFC3775]. As a router, the RPL node may advertise the information
	from the options as required for the specific link, for instance in a
	ND RA message, though the exact operation is out of scope.
	A set of companion documents to this specification will provide		A set of companion documents to this specification will provide
	further guidance in the form of applicability statements specifying a		further guidance in the form of applicability statements specifying a
	set of operating points appropriate to the Building Automation, Home		set of operating points appropriate to the Building Automation, Home
	Automation, Industrial, and Urban application scenarios.		Automation, Industrial, and Urban application scenarios.
			***Maybe we should say something about the three security modes
			here...
	1.2. Expectations of Link Layer Type		1.2. Expectations of Link Layer Type
	In compliance with the layered architecture of IP, RPL does not rely		In compliance with the layered architecture of IP, RPL does not rely
	on any particular features of a specific link layer technology. RPL		on any particular features of a specific link layer technology. RPL
	is designed to be able to operate over a variety of different link		is designed to be able to operate over a variety of different link
	layers, including ones that are constrained, potentially lossy, or		layers, including ones that are constrained, potentially lossy, or
	typically utilized in conjunction with highly constrained host or		typically utilized in conjunction with highly constrained host or
	router devices, such as but not limited to, low power wireless or PLC		router devices, such as but not limited to, low power wireless or PLC
	(Power Line Communication) technologies.		(Power Line Communication) technologies. As noted above, however,
			it is required that links are bidirectional.
	Implementers may find [RFC3819] a useful reference when designing a		Implementers may find [RFC3819] a useful reference when designing a
	link layer interface between RPL and a particular link layer		link layer interface between RPL and a particular link layer
	technology.		technology.
			1.3. Summary of Implementation Requirements
			A conforming implementation of RPL is REQUIRED to support the following
			parts:
			- An implementation of RPL itself with support either for storing
			or the non-storing modes, but not necessarily both (Section 3.3).
			- The default objective function (Section 3.2.1 specifies this as
			[I-D.ietf-roll-of0]).
			- Neighbor Unreachability Detection (NUD) is required for testing
			bidirectional reachability.
			- The IPv6 Hop-by-Hop RPL Option [I-D.ietf-6man-rpl-option].
			- The IPv6 RPL Routing Header [I-D.ietf-6man-rpl-routing-header].
			- Trickle [I-D.ietf-roll-trickle].
			- A mechanism to distribute ND information received via RPL to
			other, non-RPL nodes (subject to future work).
			In addition, if the node supports authenticated mode - one of
			the three security modes defined in Section 3.2.3 - it is also
			required to support a mechanism to obtain authentication
			material. Such a mechanism is subject to future specification.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	Additionally, this document uses terminology from		Additionally, this document uses terminology from
	[I-D.ietf-roll-terminology], and introduces the following		[I-D.ietf-roll-terminology], and introduces the following
	terminology:		terminology:
	skipping to change at page 17, line 42		skipping to change at page 17, line 42
	The Objective Function (OF) defines how RPL nodes select and optimize		The Objective Function (OF) defines how RPL nodes select and optimize
	routes within a RPL Instance. The OF is identified by an Objective		routes within a RPL Instance. The OF is identified by an Objective
	Code Point (OCP) within the DIO Configuration option. An OF defines		Code Point (OCP) within the DIO Configuration option. An OF defines
	how nodes translate one or more metrics and constraints, which are		how nodes translate one or more metrics and constraints, which are
	themselves defined in [I-D.ietf-roll-routing-metrics], into a value		themselves defined in [I-D.ietf-roll-routing-metrics], into a value
	called Rank, which approximates the node's distance from a DODAG		called Rank, which approximates the node's distance from a DODAG
	root. An OF also defines how nodes select parents. Further details		root. An OF also defines how nodes select parents. Further details
	may be found in Section 14, [I-D.ietf-roll-routing-metrics],		may be found in Section 14, [I-D.ietf-roll-routing-metrics],
	[I-D.ietf-roll-of0], and related companion specifications.		[I-D.ietf-roll-of0], and related companion specifications.
			While specialized metrics [I-D.ietf-roll-routing-metrics] can be
			useful in particular networks, a RPL implementation is not required
			to implement these metrics. For interoperability, it is REQUIRED
			that the Objective Function 0 [I-D.ietf-roll-of0] is implemented,
			however. This Objective Function can work without any specified
			metrics.
	3.2.2. DODAG Repair		3.2.2. DODAG Repair
	A DODAG Root institutes a global repair operation by incrementing the		A DODAG Root institutes a global repair operation by incrementing the
	DODAG Version Number. This initiates a new DODAG Version. Nodes in		DODAG Version Number. This initiates a new DODAG Version. Nodes in
	the new DODAG Version can choose a new position whose Rank is not		the new DODAG Version can choose a new position whose Rank is not
	constrained by their Rank within the old DODAG Version.		constrained by their Rank within the old DODAG Version.
	RPL also supports mechanisms which may be used for local repair		RPL also supports mechanisms which may be used for local repair
	within the DODAG Version. The DIO message specifies the necessary		within the DODAG Version. The DIO message specifies the necessary
	parameters as configured from and controlled by policy at the DODAG		parameters as configured from and controlled by policy at the DODAG
	skipping to change at page 20, line 20		skipping to change at page 20, line 20
	o Nodes provision routing table entries, for the destinations		o Nodes provision routing table entries, for the destinations
	specified by the DIO message, via their DODAG parents in the DODAG		specified by the DIO message, via their DODAG parents in the DODAG
	Version. Nodes that decide to join a DODAG can provision one or		Version. Nodes that decide to join a DODAG can provision one or
	more DODAG parents as the next-hop for the default route and a		more DODAG parents as the next-hop for the default route and a
	number of other external routes for the associated instance.		number of other external routes for the associated instance.
	3.3. Downward Routes and Destination Advertisement		3.3. Downward Routes and Destination Advertisement
	RPL uses Destination Advertisement Object (DAO) messages to establish		RPL uses Destination Advertisement Object (DAO) messages to establish
	downward routes. DAO messages are an optional feature for		downward routes. DAO messages are an optional feature for
	applications that require P2MP or P2P traffic. RPL supports two		applications that require P2MP or P2P traffic.
			***DAO message are optional. If I do not implement them, can I not
			send any packets downward? I'm not sure we should build protocols
			that only support one-way communication, and I suspect situations
			where this truly is sufficient are rare. Reasons relate to
			reliability, acknowledgements, destination address discovery, and
			so on. But maybe I'm missing something.
			RPL supports two
	modes of downward traffic: storing (fully stateful) or non-storing		modes of downward traffic: storing (fully stateful) or non-storing
	(fully source routed). Any given RPL Instance is either storing or		(fully source routed). Any given RPL Instance is either storing or
	non-storing. In both cases, P2P packets travel Up toward a DODAG		non-storing. In both cases, P2P packets travel Up toward a DODAG
	Root then Down to the final destination (unless the destination is on		Root then Down to the final destination (unless the destination is on
	the upward route). In the non-storing case the packet will travel		the upward route). In the non-storing case the packet will travel
	all the way to a DODAG root before traveling Down. In the storing		all the way to a DODAG root before traveling Down. In the storing
	case the packet may be directed Down towards the destination by a		case the packet may be directed Down towards the destination by a
	common ancestor of the source and the destination prior to reaching a		common ancestor of the source and the destination prior to reaching a
	DODAG Root.		DODAG Root.
End of changes. 11 change blocks.
	21 lines changed or deleted		92 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/