draft-ietf-roll-p2p-rpl-12.txt   draft-ietf-roll-p2p-rpl-13.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 9, 2012 E. Baccelli Expires: December 6, 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 8, 2012 June 4, 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-12 draft-ietf-roll-p2p-rpl-13
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 9, 2012. This Internet-Draft will expire on December 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7
6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 10
6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 10
7. New RPL Control Message Options . . . . . . . . . . . . . . . 11 7. New RPL Control Message Options . . . . . . . . . . . . . . . 13
7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 13
7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 16
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 17
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 19
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 . . 19
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 20
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 20
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 20
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . 23
9.5. Additional Processing of a P2P Mode DIO At The Target . . 23 9.5. Additional Processing of a P2P Mode DIO At The Target . . 24
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 26
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29
12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 29 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31
14.2. Additions to RPL Control Message Options . . . . . . . . . 30 14.2. Additions to RPL Control Message Options . . . . . . . . . 31
14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32
14.4. New Registry for Upper Layer Headers inside Data Option . 31 14.4. New Registry for Upper Layer Protocol Types Inside
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 Data Option . . . . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
16.2. Informative References . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 16.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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 8, line 41 skipping to change at page 9, line 41
message by sending back a DRO Acknowledgement (DRO-ACK) message message by sending back a DRO Acknowledgement (DRO-ACK) message
(defined in Section 10). The Origin unicasts a DRO-ACK message to (defined in Section 10). The Origin unicasts a DRO-ACK message to
the Target. If the Target does not receive the requested DRO-ACK the Target. If the Target does not receive the requested DRO-ACK
within a certain time interval of sending a DRO, it resends the DRO within a certain time interval of sending a DRO, it resends the DRO
message (up to a certain number of times) carrying the same route as message (up to a certain number of times) carrying the same route as
before. before.
The use of trickle timers to delay the propagation of DIO messages The use of trickle timers to delay the propagation of DIO messages
may cause some nodes to generate these messages even when the desired may cause some nodes to generate these messages even when the desired
routes have already been discovered. In order to preempt the routes have already been discovered. In order to preempt the
generation of such unnecessary messages, the Target may set a "stop" generation of such unnecessary messages, the Target may set a "Stop"
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
skipping to change at page 11, line 43 skipping to change at page 12, line 43
o MAY carry one or more RPL Target Options to specify additional o MAY carry one or more RPL Target Options to specify additional
unicast/multicast addresses for the Target. unicast/multicast addresses for the Target.
o MAY carry one or more Metric Container Options to specify routing o MAY carry one or more Metric Container Options to specify routing
metrics and constraints. metrics and constraints.
o MAY carry one Data Option (described in Section 7.2) containing o MAY carry one Data Option (described in Section 7.2) containing
time-critical application data to be delivered to the Target(s). time-critical application data to be delivered to the Target(s).
o MAY carry one or more Route Information or Prefix Information o MAY carry one or more Route Information Options [RFC6550]. In the
Options (described in [RFC6550]). context of P2P-RPL, a Route Information Option advertizes to the
Target(s) the Origin's connectivity to the prefix specified in the
option.
o MAY carry one or more Prefix Information Options subject to the
usage and rules specified in Section 6.7.10 in [RFC6550].
A router MUST discard a received P2P mode DIO if it violates any of A router MUST discard a received P2P mode DIO if it violates any of
the rules listed above. the rules listed above.
7. New RPL Control Message Options 7. New RPL Control Message Options
This document defines two new RPL control message options: the P2P This document defines two new RPL control message options: the P2P
Route Discovery Option and the Data Option. Route Discovery Option and the Data Option.
7.1. P2P Route Discovery Option (P2P-RDO) 7.1. P2P Route Discovery Option (P2P-RDO)
skipping to change at page 15, line 10 skipping to change at page 16, line 12
specifying a complete route in the Address vector MUST ensure specifying a complete route in the Address vector MUST ensure
that the vector does not contain any address more than once. that the vector does not contain any address more than once.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
7.2. Data Option 7.2. Data Option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Option Length | SeqNo | Upper | Data | | Type = 11 | Option Length | UpperLayerPrt | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of Data Option Figure 2: Format of Data Option
The format of a Data Option is illustrated in Figure 2. A P2P mode The format of a Data Option is illustrated in Figure 2. A P2P mode
DIO and a DRO (defined in Section 8) message MAY carry one or more DIO and a DRO (defined in Section 8) message MAY carry one Data
Data Options. A P2P-RDO consists of the following fields: Option. A P2P-RDO consists of the following fields:
o Option Type: 0x0B (to be confirmed by IANA). o Option Type: 0x0B (to be confirmed by IANA).
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 Upper Layer Protocol: An 8-bit field that identifies the upper
carried by the Data Option. layer protocol header with which the information in the Data field
starts. A value 0x00 in this field identifies UDP as the upper
o Upper: A 4-bit field that identifies the upper layer protocol layer protocol while the value 0xFF is reserved for Private Use as
header with which the information in the Data field starts. A defined in [RFC5226]. The other values are Unassigned [RFC5226]
value 0x0 in this field identifies UDP as the upper layer protocol 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.
If the Origin chooses to include a Data Option inside its DIO, it
MUST include the same Data Option in all its future DIO transmissions
for this temporary DAG. An Intermediate Router MUST NOT modify the
Data Option received inside a parent's DIO and MUST include this Data
Option in all its future DIO transmissions for this temporary DAG.
The same is true for a Target that needs to propagate the DIOs
further (required when the route discovery involves multiple
Targets). If a Target chooses to include a Data Option inside a DRO,
it MUST include the same Data Option in all retransmissions of this
DRO message and MUST NOT include a different Data Option in any other
DRO messages it generates for this route discovery. Also, an
Intermediate Router, which needs to forward a received DRO message
further, MUST include in the forwarded message a verbatim copy of the
Data Option found inside the received message.
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
Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves
one of the following functions: one of the following functions:
o Carry a discovered Source Route from a Target to the Origin; o Carry a discovered Source Route from a Target to the Origin;
o Establish a Hop-by-hop Route as it travels from a Target to the o Establish a Hop-by-hop Route as it travels from a Target to the
skipping to change at page 17, line 5 skipping to change at page 18, line 22
inside P2P-RDO, inside P2P-RDO,
* SHOULD NOT process any more DIOs received for this temporary * SHOULD NOT process any more DIOs received for this temporary
DAG; DAG;
* SHOULD NOT generate any more DIOs for this temporary DAG; * SHOULD NOT generate any more DIOs for this temporary DAG;
* SHOULD cancel any pending DIO transmission for this temporary * SHOULD cancel any pending DIO transmission for this temporary
DAG. DAG.
Note that the stop flag serves to stop further DIO generation/ Note that the Stop flag serves to stop further DIO generation/
processing for a P2P-RPL route discovery but it does not affect processing for a P2P-RPL route discovery but it does not affect
the processing of DRO messages at either the Origin or the the processing of DRO messages at either the Origin or the
Intermediate Routers. In other words, a router (the Origin or an Intermediate Routers. In other words, a router (the Origin or an
Intermediate Router) MUST continue to process the DRO messages Intermediate Router) MUST continue to process the DRO messages
even if an earlier DRO message (with the same RPLInstanceID and even if an earlier DRO message (with the same RPLInstanceID and
DODAGID fields) had the stop flag set to one. DODAGID fields) had the Stop flag set to one.
o Ack Required (A): This flag, when set to one by the Target, o Ack Required (A): This flag, when set to one by the Target,
indicates that the Origin MUST unicast a DRO-ACK message (defined indicates that the Origin MUST unicast a DRO-ACK message (defined
in Section 10) to the Target when it receives the DRO. in Section 10) to the Target when it receives the DRO.
o Sequence Number (Seq): This 2-bit field indicates the sequence o Sequence Number (Seq): This 2-bit field indicates the sequence
number for the DRO. This field is relevant when the A flag is set number for the DRO. This field is relevant when the A flag is set
to one, i.e., the Target requests an acknowledgement from the to one, i.e., the Target requests an acknowledgement from the
Origin for a received DRO. The Origin includes the RPLInstanceID, Origin for a received DRO. The Origin includes the RPLInstanceID,
the DODAGID and the Sequence Number of the received DRO inside the the DODAGID and the Sequence Number of the received DRO inside the
skipping to change at page 17, line 43 skipping to change at page 19, line 13
o Options: The DRO message: o Options: The DRO message:
* MUST carry one P2P-RDO that MUST specify a complete route * MUST carry one P2P-RDO that MUST specify a complete route
between the Target and the Origin; between the Target and the Origin;
* MAY carry one or more Metric Container Options that contains * MAY carry one or more Metric Container Options that contains
the aggregated routing metrics values for the route specified the aggregated routing metrics values for the route specified
in P2P-RDO; in P2P-RDO;
* MAY carry one Data Option to carry any time-critical * MAY carry one Data Option to carry any time-critical
application data to the Origin. application data to the Origin, subject to the following
conditions: if a Target chooses to include a Data Option inside
a DRO,
+ it MUST include the same Data Option in all retransmissions
of this DRO message and
+ it MUST NOT include a different Data Option in any other DRO
messages it generates for this route discovery.
The Target MAY repeat the same Data Option in multiple DRO
messages it generates for a particular route discovery.
8.1. Secure DRO 8.1. Secure DRO
A Secure DRO message follows the format in Figure 7 of [RFC6550], A Secure DRO message follows the format in Figure 7 of [RFC6550],
where the base format is the base DRO shown in Figure 3. where the base format is the base DRO shown in Figure 3.
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object
A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as
defined in Section 7.1. Specifically, the following fields MUST be defined in Section 7.1. Specifically, the following fields MUST be
skipping to change at page 19, line 5 skipping to change at page 20, line 30
All the routers participating in a P2P-RPL route discovery, including All the routers participating in a P2P-RPL route discovery, including
the Origin and the Target(s), MUST join the temporary DAG being the Origin and the Target(s), MUST join the temporary DAG being
created for the purpose. When a router joins a temporary DAG created for the purpose. When a router joins a temporary DAG
advertized by a P2P mode DIO, it SHOULD maintain its membership in advertized by a P2P mode DIO, it SHOULD maintain its membership in
the temporary DAG for the suggested Life Time duration listed in the the temporary DAG for the suggested Life Time duration listed in the
P2P-RDO. The only purpose of a temporary DAG's existence is to P2P-RDO. The only purpose of a temporary DAG's existence is to
facilitate the P2P-RPL route discovery process. The temporary DAG facilitate the P2P-RPL route discovery process. The temporary DAG
MUST NOT be used to route packets. A router SHOULD detach from the MUST NOT be used to route packets. A router SHOULD detach from the
temporary DAG once the duration of its membership in the DAG has temporary DAG once the duration of its membership in the DAG has
exceeded the DAG's life time. After receiving a DRO with the stop exceeded the DAG's life time. After receiving a DRO with the Stop
flag set to one, a router SHOULD NOT send or receive any more DIOs flag set to one, a router SHOULD NOT send or receive any more DIOs
for this temporary DAG and SHOULD also cancel any pending DIO for this temporary DAG and SHOULD also cancel any pending DIO
transmission. transmission.
9.2. Trickle Operation For P2P Mode DIOs 9.2. Trickle Operation For P2P Mode DIOs
An RPL router uses a Trickle timer [RFC6206] to control DIO An RPL router uses a Trickle timer [RFC6206] to control DIO
transmissions. The Trickle control of DIO transmissions provides transmissions. The Trickle control of DIO transmissions provides
quick resolution of any "inconsistency" while avoiding redundant DIO quick resolution of any "inconsistency" while avoiding redundant DIO
transmissions. The Trickle algorithm also imparts protection against transmissions. The Trickle algorithm also imparts protection against
skipping to change at page 21, line 47 skipping to change at page 23, line 24
o If the integer part of the rank advertised in the DIO equals or o If the integer part of the rank advertised in the DIO equals or
exceeds the MaxRank limit listed in the P2P Route Discovery exceeds the MaxRank limit listed in the P2P Route Discovery
Option. Option.
o If the router cannot evaluate the mandatory route constraints o If the router cannot evaluate the mandatory route constraints
listed in the DIO or if the routing metric values do not satisfy listed in the DIO or if the routing metric values do not satisfy
one or more of the mandatory constraints. one or more of the mandatory constraints.
o If the router previously received a DRO message with the same o If the router previously received a DRO message with the same
RPLInstanceID and DODAGID as the received DIO and with the stop RPLInstanceID and DODAGID as the received DIO and with the Stop
flag set to one. flag set to one.
The router MUST check the Target addresses listed in the P2P-RDO and The router MUST check the Target addresses listed in the P2P-RDO and
any RPL Target Options included in the received DIO. If one of its any RPL Target Options included in the received DIO. If one of its
IPv6 addresses is listed as a Target address or if it belongs to the IPv6 addresses is listed as a Target address or if it belongs to the
multicast group specified as one of the Target addresses, the router multicast group specified as one of the Target addresses, the router
considers itself a Target and processes the received DIO as specified considers itself a Target and processes the received DIO as specified
in Section 9.5. Otherwise, the router considers itself an in Section 9.5. Otherwise, the router considers itself an
Intermediate Router and processes the received DIO as specified in Intermediate Router and processes the received DIO as specified in
Section 9.4. Section 9.4.
9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router
An Intermediate Router MUST discard a received P2P mode DIO with no An Intermediate Router MUST discard a received P2P mode DIO with no
further processing if the router cannot elide Compr (as specified in further processing if the router cannot elide Compr (as specified in
the P2P-RDO) prefix octets from its IPv6 address. the P2P-RDO) prefix octets from its IPv6 address.
On receiving a P2P mode DIO, an Intermediate Router MUST do the On receiving a P2P mode DIO, an Intermediate Router MUST do the
following: following:
o The router updates the Data Option to be carried in the router's o The router MUST determine whether this DIO advertises a better
DIOs if the one in the received DIO has a higher sequence number route than the router itself and whether the receipt of the DIO
than what the router currently has (or if the router currently is would allow the router to advertise a better route than before.
not aware of any Data Option).
o The router determines whether this DIO advertises a better route
than the router itself and whether the receipt of the DIO would
allow the router to advertise a better route than before.
Accordingly, the router SHOULD consider this DIO as consistent/ Accordingly, the router SHOULD consider this DIO as consistent/
inconsistent from Trickle perspective as described in Section 9.2. inconsistent from Trickle perspective as described in Section 9.2.
Note that the route comparison in a P2P-RPL route discovery is Note that the route comparison in a P2P-RPL route discovery is
performed using the parent selection rules of the OF in use as performed using the parent selection rules of the OF in use as
specified in Section 14 of RPL [RFC6550]. If the received DIO specified in Section 14 of RPL [RFC6550]. If the received DIO
would allow the router to advertise a better route, the router would allow the router to advertise a better route, the router
MUST remember the route advertised (inside the P2P-RDO) in the DIO MUST remember the route advertised (inside the P2P-RDO) in the DIO
(after adding its own IPv6 address to the route) for inclusion in (after adding its own IPv6 address to the route) for inclusion in
its future DIOs. When an Intermediate Router adds itself to a its future DIOs. When an Intermediate Router adds itself to a
route, it MUST ensure that the IPv6 address added to the route is route, it MUST ensure that the IPv6 address added to the route is
skipping to change at page 23, line 5 skipping to change at page 24, line 21
diversity of the routes being discovered, an Intermediate Router diversity of the routes being discovered, an Intermediate Router
SHOULD keep track of multiple partial routes to be advertised in SHOULD keep track of multiple partial routes to be advertised in
the P2P-RDO inside its DIO. When the router generates its DIO, it the P2P-RDO inside its DIO. When the router generates its DIO, it
SHOULD randomly select the partial route to be included in the SHOULD randomly select the partial route to be included in the
P2P-RDO. Note that the route accumulation in a P2P mode DIO MUST P2P-RDO. Note that the route accumulation in a P2P mode DIO MUST
take place even if the Origin does not want any DRO messages to be take place even if the Origin does not want any DRO messages to be
generated (i.e., the R flag inside the P2P-RDO is set to zero). generated (i.e., the R flag inside the P2P-RDO is set to zero).
This is because the Target may still be able to use the This is because the Target may still be able to use the
accumulated route as a source route to reach the Origin. accumulated route as a source route to reach the Origin.
o The router MUST copy any Data Option (to be included in its future
DIO transmissions) if the received DIO comes from a parent and is
the first parent-originated DIO received with a Data Option
inside.
9.5. Additional Processing of a P2P Mode DIO At The Target 9.5. Additional Processing of a P2P Mode DIO At The Target
The Target MUST determine if the received DIO contains a Data Option The Target MUST determine if the received DIO contains a Data Option
and deliver the data to the specified upper layer protocol if the and deliver the data to the specified upper layer protocol unless it
option's sequence number is higher than that of the options in the has already done so in response to a previously received DIO. If
previously received DIOs for this route discovery (or if the DIOs this route discovery involves multiple Targets, the Target MUST
received earlier did not have a Data Option). If this route remember this Data Option for inclusion in its own DIOs.
discovery involves multiple Targets, the Target MUST remember the
Data Option with highest sequence number for inclusion in its own
DIOs.
The Target MAY store the route contained in the P2P-RDO in the The Target MAY store the route contained in the P2P-RDO in the
received DIO for use as a Source Route to reach the Origin. The received DIO for use as a Source Route to reach the Origin. The
lifetime of this Source Route is specified by the Default Lifetime lifetime of this Source Route is specified by the Default Lifetime
and Lifetime Unit parameters inside the DODAG Configuration Option and Lifetime Unit parameters inside the DODAG Configuration Option
currently in effect. This lifetime can be extended (or shortened) currently in effect. This lifetime can be extended (or shortened)
appropriately following a hint from an upper-layer protocol. appropriately following a hint from an upper-layer protocol.
If the Reply flag inside the P2P-RDO in the received DIO is zero, the If the Reply flag inside the P2P-RDO in the received DIO is zero, the
Target MUST discard the received DIO with no further processing. Target MUST discard the received DIO with no further processing.
skipping to change at page 24, line 10 skipping to change at page 25, line 29
causes the Target to retransmit the DRO message. The Target MAY causes the Target to retransmit the DRO message. The Target MAY
retransmit the DRO message in this fashion up to retransmit the DRO message in this fashion up to
MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and
MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided
based on the characteristics of individual deployments. Note that based on the characteristics of individual deployments. Note that
all DRO transmissions and retransmissions MUST take place while the all DRO transmissions and retransmissions MUST take place while the
Target is still a part of the temporary DAG created for the route Target is still a part of the temporary DAG created for the route
discovery. A Target MUST NOT transmit a DRO if it no longer belongs discovery. A Target MUST NOT transmit a DRO if it no longer belongs
to this DAG. to this DAG.
The Target MAY set the stop flag inside the DRO message to one if The Target MAY set the Stop flag inside the DRO message to one if
o this router is the only Target specified in the corresponding DIO, o this router is the only Target specified in the corresponding DIO,
i.e., the corresponding DIO specified a unicast address of the i.e., the corresponding DIO specified a unicast address of the
router as the Target inside the P2P-RDO with no additional Targets router as the Target inside the P2P-RDO with no additional Targets
specified via RPL Target Options; and specified via RPL Target Options; and
o the Target has already selected the desired number of routes. o the Target has already selected the desired number of routes.
The Target MAY include a Metric Container Option in the DRO message. The Target MAY include a Metric Container Option in the DRO message.
This Metric Container contains the end-to-end routing metric values This Metric Container contains the end-to-end routing metric values
for the route specified in the P2P-RDO. The Target MAY include one for the route specified in the P2P-RDO. The Target MAY include one
Data Option in the DRO message to carry time-critical application Data Option in the DRO message to carry time-critical application
data for the Origin. Note that this Data Option is not same as the data for the Origin, subject to the conditions listed in Section 8.
Data Option that the Target may include in the DIOs it generates for The Target MUST transmit the DRO message via a link-local multicast.
this route discovery (if the route discovery involves multiple
Targets). The Target MUST transmit the DRO message via a link-local
multicast.
A Target MUST NOT forward a P2P mode DIO any further if no other A Target MUST NOT forward a P2P mode DIO any further if no other
Targets are to be discovered, i.e., if a unicast IPv6 address (of Targets are to be discovered, i.e., if a unicast IPv6 address (of
this Target) is specified as the Target inside the P2P-RDO and no this Target) is specified as the Target inside the P2P-RDO and no
additional Targets are specified via RPL Target Options inside the additional Targets are specified via RPL Target Options inside the
DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery. Otherwise, the Target MUST generate
DIOs for this route discovery as an Intermediate Router would. DIOs for this route discovery as an Intermediate Router would.
9.6. Processing a DRO At An Intermediate Router 9.6. Processing a DRO At An Intermediate Router
If the DODAGID field in the received DRO does not list a router's own If the DODAGID field in the received DRO does not list a router's own
IPv6 address, the router considers itself an Intermediate Router and IPv6 address, the router considers itself an Intermediate Router and
MUST process the received message in the following manner: MUST process the received message in the following manner:
o The router MUST discard the received DRO with no further o The router MUST discard the received DRO with no further
processing if it does not belong to the temporary DAG identified processing if it does not belong to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO. by the RPLInstanceID and the DODAGID fields in the DRO.
o If the stop flag inside the received DRO is set to one, the router o If the Stop flag inside the received DRO is set to one, the router
SHOULD NOT send or receive any more DIOs for this temporary DAG SHOULD NOT send or receive any more DIOs for this temporary DAG
and SHOULD cancel any pending DIO transmission. and SHOULD cancel any pending DIO transmission.
o The router MUST ignore any Metric Container and Data Options o The router MUST ignore any Metric Container and Data Options
contained in the DRO message. contained in the DRO message.
o If Address[NH] element inside the P2P-RDO lists the router's own o If Address[NH] element inside the P2P-RDO lists the router's own
unicast IPv6 address, the router is a part of the route carried in unicast IPv6 address, the router is a part of the route carried in
the P2P-RDO. In this case, the router MUST do the following: the P2P-RDO. In this case, the router MUST do the following:
skipping to change at page 25, line 41 skipping to change at page 27, line 9
mode DIOs for this route discovery. mode DIOs for this route discovery.
* If the router already maintains a hop-by-hop state listing the * If the router already maintains a hop-by-hop state listing the
Target as the destination and carrying same RPLInstanceID and Target as the destination and carrying same RPLInstanceID and
DODAGID fields as the received DRO and the next hop information DODAGID fields as the received DRO and the next hop information
in the state does not match the next hop indicated in the in the state does not match the next hop indicated in the
received DRO, the router MUST discard the DRO message with no received DRO, the router MUST discard the DRO message with no
further processing. further processing.
* The router MUST decrement the NH field inside the P2P-RDO and * The router MUST decrement the NH field inside the P2P-RDO and
send the DRO further via link-local multicast. send the DRO message further via link-local multicast.
9.7. Processing a DRO At The Origin 9.7. Processing a DRO At The Origin
When a router receives a DRO message that lists its IPv6 address in When a router receives a DRO message that lists its IPv6 address in
the DODAGID field, the router recognizes itself as the Origin for the the DODAGID field, the router recognizes itself as the Origin for the
corresponding P2P-RPL route discovery and processes the message in corresponding P2P-RPL route discovery, notes the Target that
the following manner: originated this message (from the Target field inside the P2P-RDO)
and processes the message in the following manner:
o The Origin MUST discard the received DRO with no further o The Origin MUST discard the received DRO with no further
processing if it no longer belongs to the temporary DAG identified processing if it no longer belongs to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO. by the RPLInstanceID and the DODAGID fields in the DRO.
o The Origin MUST check if the received DRO contains a Data Option o If the received DRO contains a Data Option and if it has not
with higher sequence number than what was received previously (or already done so following the receipt of an earlier DRO from this
if this Data Option is the first one received). In that case, the Target, the Origin MUST deliver the data inside the Data Option to
Origin MUST deliver the data inside the Data Option to the upper the specified upper layer protocol.
layer protocol identified inside the Data Option.
o If the stop flag inside the received DRO is set to one, the Origin o If the Stop flag inside the received DRO is set to one, the Origin
SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD NOT generate any more DIOs for this temporary DAG and
SHOULD cancel any pending DIO transmission. SHOULD cancel any pending DIO transmission.
o If the P2P-RDO inside the DRO identifies the discovered route as a o If the P2P-RDO inside the DRO has the H flag set to 0, the Address
Source Route (H=0), the Origin MUST store in its memory the vector inside the P2P-RDO contains a Source Route to this Target
discovered route contained in the Address vector. The lifetime of and the Origin MUST store this Source Route in its memory. The
this Source Route is specified by the Default Lifetime and lifetime of this Source Route is specified by the Default Lifetime
Lifetime Unit parameters inside the DODAG Configuration Option in and Lifetime Unit parameters inside the DODAG Configuration Option
the P2P mode DIOs used for this route discovery. This lifetime in the P2P mode DIOs used for this route discovery. This lifetime
could be extended (or shortened) appropriately following a hint could be extended (or shortened) appropriately following a hint
from an upper-layer protocol. from an upper-layer protocol.
o If the P2P-RDO inside the DRO identifies the discovered route as a o If the P2P-RDO inside the DRO has the H flag set to 1, the DRO
Hop-by-hop Route (H=1), the Origin MUST store in its memory the message is establishing a Hop-by-hop Route to this Target and the
state for the discovered route in the manner described in Origin MUST store in its memory the state for this Hop-by-hop
Section 9.6. This hop-by-hop routing state MUST expire at the end Route in the manner described in Section 9.6. This hop-by-hop
of the lifetime specified by the Default Lifetime and Lifetime routing state MUST expire at the end of the lifetime specified by
Unit parameters inside the DODAG Configuration Option used in P2P the Default Lifetime and Lifetime Unit parameters inside the DODAG
mode DIOs for this route discovery. The standards track version Configuration Option used in P2P mode DIOs for this route
of P2P-RPL may consider specifying a signaling mechanism that will discovery. The standards track version of P2P-RPL may consider
allow the Origin to extend (or shorten) the lifetime of a P2P-RPL specifying a signaling mechanism that will allow the Origin to
Hop-by-hop Route following a suitable hint from an upper-layer extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route
protocol. following a suitable hint from an upper-layer protocol.
o If the received DRO message contains one or more Metric Container o If the received DRO message contains one or more Metric Container
Options, the Origin MAY store the values of the routing metrics Options, the Origin MAY store the values of the routing metrics
associated with the discovered route in its memory. This associated with the discovered route in its memory. This
information may be useful in formulating the constraints for any information may be useful in formulating the constraints for any
future P2P-RPL route discovery to the Target. future P2P-RPL route discovery to this Target.
o If the A flag is set to one in the received DRO message, the o If the A flag is set to one in the received DRO message, the
Origin MUST generate a DRO-ACK message as described in Section 10 Origin MUST generate a DRO-ACK message as described in Section 10
and unicast the message to the Target (identified by the Target and unicast the message to the Target. The Origin MAY use the
field inside the P2P-RDO). The Origin MAY use the route just route just discovered to send the DRO-ACK message to the Target.
discovered to send the DRO-ACK message to the Target. Section 11 Section 11 describes how a packet may be forwarded along a Source/
describes how a packet may be forwarded along a source/Hop-by-hop Hop-by-hop Route discovered using P2P-RPL.
Route discovered using P2P-RPL.
10. The Discovery Reply Object Acknowledgement (DRO-ACK) 10. The Discovery Reply Object Acknowledgement (DRO-ACK)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |Seq| Reserved | | RPLInstanceID | Version |Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID | | DODAGID |
skipping to change at page 31, line 29 skipping to change at page 32, line 45
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| 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 Protocol Types Inside Data Option
The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for The Data Option (see Section 7.2) defines an 8-bit "Upper Layer
which IANA is requested to create and maintain a new registry titled Protocol" field, for which IANA is requested to create and maintain a
"Upper Layer Header Type Inside RPL Data Option". New codes may be new registry titled "Upper Layer Protocol Types Inside RPL Data
allocated in this registry only by an IETF Review [RFC5226]. Each Option". New codes may be allocated in this registry only by an IETF
code is tracked with the following characteristics: Review [RFC5226]. Each code is tracked with the following
characteristics:
o Value o Value
o Description o Description
o Reference o Reference
The following codes are currently defined: The following codes are currently defined:
+---------+-------------+---------------+ +-----------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+---------+-------------+---------------+ +-----------+-------------+---------------+
| 0x0 | UDP Header | This document | | 0x00 | UDP Header | This document |
| 0x1-0xE | Unassigned | | | 0x01-0xFE | Unassigned | |
| 0xF | Private Use | This document | | 0xFF | Private Use | This document |
+---------+-------------+---------------+ +-----------+-------------+---------------+
Upper Layer Header Types Inside RPL Data Option Upper Layer Protocol 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, Cedric Chauvenet, Thomas
Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP Clausen, Robert Cragie, Ted Humpal, Richard Kelsey, Phil Levis,
Vasseur. Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby,
Pascal Thubert, Hristo Valev and JP 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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
skipping to change at page 33, line 5 skipping to change at page 34, line 15
[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
Low-Power and Lossy Networks", RFC 6551, March 2012. Low-Power and Lossy Networks", RFC 6551, March 2012.
16.2. Informative References 16.2. Informative References
[I-D.ietf-roll-p2p-measurement] [I-D.ietf-roll-p2p-measurement]
Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
Mechanism to Measure the Quality of a Point-to-point Route Mechanism to Measure the Quality of a Point-to-point Route
in a Low Power and Lossy Network", in a Low Power and Lossy Network",
draft-ietf-roll-p2p-measurement-04 (work in progress), draft-ietf-roll-p2p-measurement-05 (work in progress),
March 2012. May 2012.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
 End of changes. 37 change blocks. 
131 lines changed or deleted 157 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/