draft-ietf-roll-nsa-extension-08.txt   draft-ietf-roll-nsa-extension-09.txt 
ROLL R.-A. Koutsiamanis, Ed. ROLL R.-A. Koutsiamanis, Ed.
Internet-Draft G.Z. Papadopoulos Internet-Draft G.Z. Papadopoulos
Intended status: Standards Track N. Montavont Intended status: Standards Track N. Montavont
Expires: 28 September 2020 IMT Atlantique Expires: 30 March 2021 IMT Atlantique
P. Thubert P. Thubert
Cisco Cisco
27 March 2020 26 September 2020
Common Ancestor Objective Function and Parent Set DAG Metric Container Common Ancestor Objective Function and Parent Set DAG Metric Container
Extension Extension
draft-ietf-roll-nsa-extension-08 draft-ietf-roll-nsa-extension-09
Abstract Abstract
Packet Replication and Elimination is a method in which several Packet Replication and Elimination is a method in which several
copies of a data packet are sent in the network in order to achieve copies of a data packet are sent in the network in order to achieve
high reliability and low jitter. This document details how to apply high reliability and low jitter. This document details how to apply
Packet Replication and Elimination in RPL, especially how to exchange Packet Replication and Elimination in RPL, especially how to exchange
information within RPL control packets to let a node better select information within RPL control packets to let a node better select
the different parents that will be used to forward the multiple the different parents that will be used to forward the multiple
copies of a packet. This document also describes the Objective copies of a packet. This document also describes the Objective
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 28 September 2020. This Internet-Draft will expire on 30 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4 3. Common Ancestor AP Selection Policies . . . . . . . . . . . . 4
3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5 3.1. Common Ancestor Strict . . . . . . . . . . . . . . . . . 5
3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6 3.2. Common Ancestor Medium . . . . . . . . . . . . . . . . . 6
3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6 3.3. Common Ancestor Relaxed . . . . . . . . . . . . . . . . . 6
4. Common Ancestor Objective Function . . . . . . . . . . . . . 6 4. Common Ancestor Objective Function . . . . . . . . . . . . . 6
4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Node State and Attribute (NSA) object type extension . . . . 9 5. Node State and Attribute (NSA) object type extension . . . . 9
5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 12 6. Controlling PRE . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Informative references . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Other Informative References . . . . . . . . . . . . . . 14 10.1. Informative references . . . . . . . . . . . . . . . . . 13
Appendix A. Implementation Status . . . . . . . . . . . . . . . 14 Appendix A. Implementation Status . . . . . . . . . . . . . . . 14
Appendix B. Choosing an AP selection policy . . . . . . . . . . 16 Appendix B. Choosing an AP selection policy . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Networks in the industrial context must provide stringent guarantees Networks in the industrial context must provide stringent guarantees
in terms of reliability and predictability, with this domain being in terms of reliability and predictability, with this domain being
one of main ones addressed by Deterministic Networking [RFC8557]. one of main ones addressed by Deterministic Networking [RFC8557].
Packet Replication and Elimination (PRE) Packet Replication and Elimination (PRE) (Section 4.5.3 of
[I-D.papadopoulos-raw-pareo-reqs] is a technique which allows [I-D.ietf-6tisch-architecture]) is a technique which allows redundant
redundant paths in the network to be utilized for traffic requiring paths in the network to be utilized for traffic requiring higher
higher reliability. Allowing industrial applications to function reliability. Allowing industrial applications to function over
over wireless networks requires the application of the principles and wireless networks requires the application of the principles and
architecture of Deterministic Networking [RFC8655]. This results in architecture of Deterministic Networking [RFC8655]. This results in
designs which aim at optimizing packet delivery rate and bounding designs which aim at optimizing packet delivery rate and bounding
latency. Additionally, nodes operating on battery need to minimize latency. Additionally, nodes operating on battery need to minimize
their energy consumption. their energy consumption.
As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154] As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154]
provides Time-Slotted Channel Hopping (TSCH), a mode of operation provides Time-Slotted Channel Hopping (TSCH), a mode of operation
which uses a common communication schedule based on timeslots to which uses a common communication schedule based on timeslots to
allow deterministic medium access as well as channel hopping to work allow deterministic medium access as well as channel hopping to work
around radio interference. However, since TSCH uses retransmissions around radio interference. However, since TSCH uses retransmissions
in the event of a failed transmission, end-to-end latency and jitter in the event of a failed transmission, end-to-end latency and jitter
performance can deteriorate. performance can deteriorate.
Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE Furthermore, the 6TiSCH working group, focusing on IPv6 over IEEE
Std. 802.15.4-TSCH, has worked on these issues and produced the Std. 802.15.4-TSCH, has worked on these issues and produced the
"6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to address that
case. Building on this architecture, "Exploiting Packet Replication case.
and Elimination in Complex Tracks in LLNs"
[I-D.papadopoulos-raw-pareo-reqs] leverages PRE to improve the Packet
Delivery Ratio (PDR), to provide a hard bound to the end-to-end
latency, and thus to limit jitter.
PRE is a general method of maximizing packet delivery rate and PRE is a general method of maximizing packet delivery rate and
potentially minimizing latency and jitter, not limited to 6TiSCH. potentially minimizing latency and jitter, not limited to 6TiSCH.
More specifically, PRE achieves controlled redundancy by laying More specifically, PRE achieves controlled redundancy by laying
multiple forwarding paths through the network and using them in multiple forwarding paths through the network and using them in
parallel for different copies of a same packet. PRE can follow the parallel for different copies of a same packet. PRE can follow the
Destination-Oriented Directed Acyclic Graph (DODAG) formed by [RPL] Destination-Oriented Directed Acyclic Graph (DODAG) formed by [RPL]
from a node to the root. Building a multi-path DODAG can be achieved from a node to the root. Building a multi-path DODAG can be achieved
based on the RPL capability of having multiple parents for each node based on the RPL capability of having multiple parents for each node
in a network, a subset of which is used to forward packets. In order in a network, a subset of which is used to forward packets. In order
skipping to change at page 4, line 16 skipping to change at page 4, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The draft uses the following Terminology: The draft uses the following Terminology:
Packet Replication and Elimination (PRE): A method which consists of Packet Replication and Elimination (PRE): A method which consists of
transmitting multiple copies of a packet using multi-path transmitting multiple copies of a packet using multi-path
forwarding over a multi-hop network and which consolidates forwarding over a multi-hop network and which consolidates
multiple received packet copies to control flooding. See multiple received packet copies to control flooding. See "Complex
"Exploiting Packet Replication and Elimination in Complex Tracks Track with Replication and Elimination" in Section 4.5.3 of
in LLNs" [I-D.papadopoulos-raw-pareo-reqs] for more details. [I-D.ietf-6tisch-architecture] for more details.
Parent Set (PS): Given a RPL node, the set of its neighbor nodes Parent Set (PS): Given a RPL node, the set of its neighbor nodes
which participate in the same RPL DODAG and which can potentially which participate in the same RPL DODAG and which can potentially
take the role of the node's preferred parent. take the role of the node's preferred parent.
Alternative Parent (AP): A RPL parent in the parent set of a node Alternative Parent (AP): A RPL parent in the parent set of a node
which is used to forward a packet copy when replicating packets. which is used to forward a packet copy when replicating packets.
Alternative Parent (AP) Selection: The mechanism for choosing the Alternative Parent (AP) Selection: The mechanism for choosing the
next hop node to forward a packet copy when replicating packets. next hop node to forward a packet copy when replicating packets.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
| \ // | \ // || \ / || PS(B) = {W, X, Y} | \ // | \ // || \ / || PS(B) = {W, X, Y}
| // | // || / || PP(B) = Y | // | // || / || PP(B) = Y
| // \ | // \ || / \ || | // \ | // \ || / \ ||
| // \ | // \ || / \ || PS(C) = {X, Y, Z} | // \ | // \ || / \ || PS(C) = {X, Y, Z}
( A ) ( B ) ( C ) ( D ) PP(C) = Y ( A ) ( B ) ( C ) ( D ) PP(C) = Y
^ ^ ^^ ^ ^ ^ ^^ ^
\ \ || / PS(D) = {Y, Z} \ \ || / PS(D) = {Y, Z}
\ \ || / PP(D) = Z \ \ || / PP(D) = Z
\ \ || / \ \ || /
\----\\ || / || Preferred Parent \----\\ || / || Preferred Parent
( S ) source | Potential Alternative Parent ( S ) source | Potential Alt. Parent
Figure 1: Example Common Ancestor Strict Alternative Parent Figure 1: Example Common Ancestor Strict Alternative Parent
Selection policy Selection policy
For example, in Figure 1, the source node S must know its grandparent For example, in Figure 1, the source node S must know its grandparent
sets through nodes A, B, C, and D. The Parent Sets (PS) and the sets through nodes A, B, C, and D. The Parent Sets (PS) and the
Preferred Parents (PS) of nodes A, B, C, and D are shown on the side Preferred Parents (PS) of nodes A, B, C, and D are shown on the side
of the figure. The CA Strict parent selection policy will select an of the figure. The CA Strict parent selection policy will select an
AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) = AP for node S for which PP(PP(S)) = PP(AP). Given that PP(PP(S)) =
Y: Y:
skipping to change at page 6, line 46 skipping to change at page 6, line 46
* Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z} * Node D: PS(D) = {Y, Z} and the common nodes are {Y, Z}
node S can decide to use node A, B or D as its AP node. node S can decide to use node A, B or D as its AP node.
4. Common Ancestor Objective Function 4. Common Ancestor Objective Function
An OF which allows the multiple paths to remain correlated is An OF which allows the multiple paths to remain correlated is
detailed here. More specifically, when using this OF a node will detailed here. More specifically, when using this OF a node will
select an AP node close to its PP node to allow the operation of select an AP node close to its PP node to allow the operation of
overhearing between parents. For more details about overhearing and overhearing between parents. For more details about overhearing and
its use in this context see the "Promiscuous Overhearing" Section 4.3 its use in this context see the "Complex Track with Replication and
of [I-D.papadopoulos-raw-pareo-reqs]. If multiple potential APs Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture]. If
match this condition, the AP with the lowest rank will be registered. multiple potential APs match this condition, the AP with the lowest
rank will be registered.
The OF described here is an extension of The Minimum Rank with The OF described here is an extension of The Minimum Rank with
Hysteresis Objective Function [MRHOF]. In general, this OF extends Hysteresis Objective Function [MRHOF]. In general, this OF extends
MRHOF by specifying how an AP is selected. Importantly, the MRHOF by specifying how an AP is selected. Importantly, the
calculation of the rank of the node through each candidate neighbor calculation of the rank of the node through each candidate neighbor
and the selection of the PP is kept the same as in MRHOF. and the selection of the PP is kept the same as in MRHOF.
The ways in which the CA OF modifies MRHOF in a section-by-section The ways in which the CA OF modifies MRHOF in a section-by-section
manner follows in detail: manner follows in detail:
skipping to change at page 10, line 41 skipping to change at page 10, line 41
type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA type (DAGMC Type in Figure 2) has the value 0x02 as per the IANA
registry for the RPL Control Message Options, and is defined in registry for the RPL Control Message Options, and is defined in
[RPL]. The DAG Metric Container option length (DAGMC Length in [RPL]. The DAG Metric Container option length (DAGMC Length in
Figure 2) expresses the DAG Metric Container length in bytes. DAG Figure 2) expresses the DAG Metric Container length in bytes. DAG
Metric Container data holds the actual data and is shown expanded in Metric Container data holds the actual data and is shown expanded in
Figure 3. Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |MC |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Flags |A|O| PS type | PS Length | | | Res | Flags |A|O| PS type | PS Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NSA +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PS IPv6 address(es) ... | | PS IPv6 address(es) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DAG Metric Container (MC) data with Node State and Figure 3: DAG Metric Container (MC) data with Node State and
Attribute (NSA) object body and a TLV Attribute (NSA) object body and a TLV
The structure of the DAG Metric Container data in the form of a Node The structure of the DAG Metric Container data in the form of a Node
State and Attribute (NSA) object with a TLV in the NSA Optional TLVs State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
field is shown in Figure 3. The first 32 bits comprise the DAG field is shown in Figure 3. The first 32 bits comprise the DAG
Metric Container header and all the following bits are part of the Metric Container header and all the following bits are part of the
Node State and Attribute object body, as defined in [RFC6551]. This Node State and Attribute object body, as defined in [RFC6551]. This
skipping to change at page 12, line 46 skipping to change at page 13, line 5
8. IANA Considerations 8. IANA Considerations
This proposal requests the allocation of a new value TBD1 from the This proposal requests the allocation of a new value TBD1 from the
"Objective Code Point (OCP)" sub-registry of the "Routing Protocol "Objective Code Point (OCP)" sub-registry of the "Routing Protocol
for Low Power and Lossy Networks (RPL)" registry. for Low Power and Lossy Networks (RPL)" registry.
This proposal also requests the allocation of a new value TBD2 for This proposal also requests the allocation of a new value TBD2 for
the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub- the "Parent Set" TLV from the Routing Metric/Constraint TLVs sub-
registry from IANA. registry from IANA.
9. References 9. Acknowledgments
9.1. Informative references We are very grateful to Dominique Barthel, Rahul Jadhav, Fabrice
Theoleyre, Diego Dujovne, Derek Jianqiang Hou, and Michael Richardson
for their comments, feedback, and support which lead to many
improvements to this document. We would also like to thank Tomas
Lagos Jenschke very much for helping in the implementation and
evaluation of the proposals of this document.
10. References
10.1. Informative references
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-29, 27 August 2020,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-29>.
[I-D.papadopoulos-raw-pareo-reqs] [IEEE802154]
Papadopoulos, G., Koutsiamanis, R., Montavont, N., and P. IEEE standard for Information Technology, "IEEE Std.
Thubert, "Exploiting Packet Replication and Elimination in 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
Complex Tracks in LLNs", Work in Progress, Internet-Draft, and Physical Layer (PHY) Specifications for Low-Rate
draft-papadopoulos-raw-pareo-reqs-01, 2 January 2020, Wireless Personal Area Networks", December 2015,
<https://tools.ietf.org/html/draft-papadopoulos-raw-pareo- <http://standards.ieee.org/findstds/
reqs-01>. standard/802.15.4-2015.html>.
[MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with [MRHOF] Gnawali, O. and P. Levis, "The Minimum Rank with
Hysteresis Objective Function", RFC 6719, Hysteresis Objective Function", RFC 6719,
DOI 10.17487/RFC6719, September 2012, DOI 10.17487/RFC6719, September 2012,
<https://www.rfc-editor.org/info/rfc6719>. <https://www.rfc-editor.org/info/rfc6719>.
[OF0] Thubert, P., Ed., "Objective Function Zero for the Routing [OF0] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
skipping to change at page 14, line 5 skipping to change at page 14, line 21
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
9.2. Other Informative References
[IEEE802154]
IEEE standard for Information Technology, "IEEE Std
802.15.4 Standard for Low-Rate Wireless Personal Area
Networks (WPANs)", December 2015.
Appendix A. Implementation Status Appendix A. Implementation Status
A research-stage implementation of the PRE mechanism using the A research-stage implementation of the PRE mechanism using the
proposed extension as part of a 6TiSCH IOT use case was developed at proposed extension as part of a 6TiSCH IOT use case was developed at
IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris IMT Atlantique, France by Tomas Lagos Jenschke and Remous-Aris
Koutsiamanis. It was implemented on the open-source Contiki OS and Koutsiamanis. It was implemented on the open-source Contiki OS and
tested with the Cooja simulator. The DIO DAGMC NSA extension is tested with the Cooja simulator. The DIO DAGMC NSA extension is
implemented with a configurable number of parents from the parent set implemented with a configurable number of parents from the parent set
of a node to be reported. of a node to be reported.
skipping to change at page 15, line 27 skipping to change at page 15, line 37
Radio Links: Every 60 s, a new Packet Delivery Rate is randomly Radio Links: Every 60 s, a new Packet Delivery Rate is randomly
drawn for each link, with a uniform distribution spanning the 70% drawn for each link, with a uniform distribution spanning the 70%
to 100% interval. to 100% interval.
Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5 Traffic Pattern: CBR, S sends one non-fragmented UDP packet every 5
seconds to R. seconds to R.
PS extension size: 3 parents. PS extension size: 3 parents.
Routing Methods: * RPL: The default RPL non-PRE implementation in Routing Methods:
Contiki OS. * RPL: The default RPL non-PRE implementation in Contiki OS.
* 2nd ETX: PRE with a parent selection method * 2nd ETX: PRE with a parent selection method which picks as AP
which picks as AP the 2nd best parent in the parent set based the 2nd best parent in the parent set based on ETX.
on ETX.
* CA Strict: As described in Section 3.1. * CA Strict: As described in Section 3.1.
* CA Medium: As described in Section 3.2. * CA Medium: As described in Section 3.2.
Simulation results: Simulation results:
+---------+-------------------+-------------------+---------------+ +=========+===================+===================+===============+
| Routing | Average Packet | Average Traversed | Average | | Routing | Average Packet | Average Traversed | Average |
| Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ | | Method | Delivery Rate (%) | Nodes/packet (#) | Duplications/ |
| | | | packet (#) | | | | | packet (#) |
+=========+===================+===================+===============+ +=========+===================+===================+===============+
| RPL | 82.70 | 5.56 | 7.02 | | RPL | 82.70 | 5.56 | 7.02 |
+---------+-------------------+-------------------+---------------+ +---------+-------------------+-------------------+---------------+
| 2nd ETX | 99.38 | 14.43 | 31.29 | | 2nd ETX | 99.38 | 14.43 | 31.29 |
+---------+-------------------+-------------------+---------------+ +---------+-------------------+-------------------+---------------+
| CA | 97.32 | 9.86 | 18.23 | | CA | 97.32 | 9.86 | 18.23 |
| Strict | | | | | Strict | | | |
skipping to change at page 17, line 9 skipping to change at page 17, line 9
may be increased jitter. may be increased jitter.
Finally, a network configurator may provide the CA policies with a Finally, a network configurator may provide the CA policies with a
preference order of Strict > Medium > Relaxed as a means of falling preference order of Strict > Medium > Relaxed as a means of falling
back to more flood-prone policies to maintain reliability. back to more flood-prone policies to maintain reliability.
Authors' Addresses Authors' Addresses
Remous-Aris Koutsiamanis (editor) Remous-Aris Koutsiamanis (editor)
IMT Atlantique IMT Atlantique
Office B00 - 126A Office B215
2 Rue de la Chataigneraie 4 rue Alfred Kastler, BP 20722
35510 Cesson-Sevigne - Rennes 44307 Nantes Cedex 3
France France
Phone: +33 299 12 70 49
Email: aris@ariskou.com Email: aris@ariskou.com
Georgios Papadopoulos Georgios Papadopoulos
IMT Atlantique IMT Atlantique
Office B00 - 114A Office B00 - 114A
2 Rue de la Chataigneraie 2 Rue de la Chataigneraie
35510 Cesson-Sevigne - Rennes 35510 Cesson-Sevigne - Rennes
France France
Phone: +33 299 12 70 04 Phone: +33 299 12 70 04
 End of changes. 24 change blocks. 
57 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/